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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The present document specifies or references procedures used on the Base Station System (BSS) to Serving GPRS 
Support Node (SGSN) interface for control of GSM packet data services within the digital cellular telecommunications 
system (Phase 2+). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies or references procedures used on the Base Station System (BSS) to Serving GPRS 
Support Node (SGSN) interface for control of GSM packet data services. 

The functional split between BSS and SGSN is defined in 3GPP TS 23.060 which states that a BSS is responsible for 
local radio resource allocation. The required procedures between BSS and SGSN are defined in detail in the present 
document. 
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3 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 and in 3GPP TS 48.016 and the 
following apply: 

ABQP Aggregate BSS QoS Profile 

CBL Current Bucket Level 

CCN Cell Change Notification 

CS Circuit switched 

CSG Closed Subscriber Group 

DL Downlink 

eNB E-UTRAN NodeB 

E-UTRA Evolved UTRA 

E-UTRAN Evolved UTRAN 

GWCN Gateway Core Network 

LCS Location Services 

MBMS Multimedia Broadcast Multicast Service 

MME Mobility Management Entity 

MOCN Multi Operator Core Network 

NACC Network Assisted Cell Change 

NSE Network Service Entity 

PEC Packet Flow Context 

PFl Packet Flow Identifier 

PFM Packet Flow Management 

PET Packet Flow Timer 

PS Packet switched 

RAN Radio Access Network 

RIM RAN Information Management 

RRLP Radio Resource LCS Protocol 

RSN RIM Sequence Number 

SIRUG Service Identification for improved Radio Utilization for GERAN 

SON Self-Organizing Networks 

SPID Subscriber Profile ID for RAT/Frequency priority 

TAI Tracking Area Identity 

TMGI Temporary Mobile Group Identity 

TOM Tunneling of Messages 

RIM RAN Information Management 

UL Uphnk 



3.1 Vocabulary 



Network sharing: network sharing is an optional feature that allows different core network operators to connect 
to the same shared radio access network (see 3GPP TS 23.251 [43]). When network sharing is in use within a 
given cell, the network broadcasts within system information the PLMN identities of the PLMNs sharing the 
cell. A mobile station supporting network sharing uses this information for its PLMN (re)selection processes and 
indicates the selected PLMN to the BSS. 
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4 Logical configuration of the Gb-interface 

4.1 High-level characteristics of the Gb-interface 

In contrast to the A-interface, where a single user has the sole use of a dedicated physical resource throughout the 
lifetime of a call irrespective of information flow, the Gb-interface allows many users to be multiplexed over a common 
physical resource. 

GPRS signalling and user data may be sent on the same physical resources. 

Access rates per user may vary from zero data to the maximum possible bandwidth (e.g. the available bit rate of an El). 

4.2 Position of BSSGP within the protocol stack on the Gb- 
interface 

Across the Gb-interface the following peer protocols have been identified: the Base Station Subsystem GPRS Protocol 
(BSSGP) and the underlying network service (NS). The NS shall transport BSSGP PDUs between a BSS and an SGSN 
(refer to 3GPPTS 48.016). 
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Figure 4.1 : BSSGP's position withiin thie Gb-interface protocol stack 

NOTE: The Relay function provides buffering and parameter mapping between the RLC/MAC and the BSSGP. 

EXAMPLE: On the uplink the RLC/MAC shall provide a TLLI. The Relay function shall then make it 
available to BSSGP. For a definition of the RLC/MAC function refer to 3GPP TS 43.064. 

The primary functions of the BSSGP include: 

in the downlink, the provision by an SGSN to a BSS of radio related information used by the RLC/MAC 
function; 

in the uplink, the provision by a BSS to an SGSN of radio related information derived from the RLC/MAC 
function; and 

the provision of functionality to enable two physically distinct nodes, an SGSN and a BSS, to operate node 
management control functions. 

The present document describes the service model, service primitives, procedures and PDU formats of the BSSGP. 
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Elements for layer-to-layer communication 



5.1 



Definition of service model 



In the present document, the communication between adjacent layers and the services provided by the layers are 
distributed by use of abstract service primitives. Only externally observable behaviour resulting from the description is 
normatively prescribed by the present document. 

The service primitive model used in the present document is based on the concepts developed in ITU-T 
Recommendation X.200. 

The service model for a BSS and an SGSN is asymmetric. The service models for a BSS and an SGSN are shown in 
figure 5.1. 
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Figure 5.1 : BSSGP service model 

Primitives consist of commands and their respective responses associated with the services requested of another layer. 
The general syntax of a primitive is: 

XX - Generic name - Type (Parameters); 

where XX designates the layer providing or using the service. 

In the present document, XX is: 

"BSSGP" for functions controlling the transfer of LLC frames passed between an SGSN and an MS across the 
Gb interface; 



"RL" (relay) for functions controlling the transfer of LLC frames between the RLC/MAC function and BSSGP; 

"GMM" (GPRS mobility management) for functions associated with mobility management between an SGSN 
and a BSS; and 



"NM" (network management) for functions associated with Gb-interface and BSS-SGSN node management; 



"PFM" (packet flow management) for functions associated with the management of BSS Packet Flow Contexts 
(PFCs); 



LCS" (location services) for functions associated with location services (LCS) procedures; 
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"RIM" (RAN Information Management) for functions associated with generic procedures to communicate 
between two BSSs over the core network. 

"MBMS" (Multimedia Broadcast Multicast Service) for functions associated with Multimedia Broadcast 
Multicast Service (MBMS) procedures. 
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5.2 Service primitives provided by the BSSGP at a BSS 

Table 5.2: Service primitives provided by BSSGP at a BSS 



Generic name 


Type 


Parameters 


REQuest 1 INDication 1 RESponse 1 CoNFirm 


RL <» BSSGP 1 


RL-DL-UNITDATA 




X 






BVCI, NSEI, 

Refer to DL-UNITDATA 

PDU 


RL-UL-UNITDATA 


X 








BVCI, NSEI, 

LSP, 

Refer to UL- UNITDATA 

PDU 


RL-DL-MBMS-UNITDATA 




X 






BVCI, NSEI, 
Refer to DL-MBMS- 
UNITDATA PDU 


RL-UL-MBMS-UNITDATA 


X 








BVCI, NSEI, 

LSP, 

Refer to UL-MBMS- 

UNITDATA PDU 


GMIVI <» BSSGP 1 


GMM-PAGING 




X 






BVCI, NSEI, 

Refer to PAGING PS PDU 

Refer to PDU PAGING CS 

PDU 


GMM-RA-CAPABILITY 




X 






BVCI, NSEI, 

Refer to RA-CAPABILITY 

PDU 


GMM-RA-CAPABILITY- 
UPDATE 


X 






X 


BVCI, NSEI, 

Refer to RA-CAPABILITY- 

UPDATE PDU, 

Refer to RA-CAPABILITY- 

UPDATE-ACK PDU 


GMM-RADIO-STATUS 


X 








BVCI, NSEI, 

Refer to RADIO-STATUS 

PDU 


GMM-SUSPEND 


X 






X 


BVCI, NSEI, 

Refer to SUSPEND PDU 
Refer to SUSPEND- 
(N)ACK PDU 


GMM-RESUME 


X 






X 


BVCI, NSEI, 

Refer to RESUME PDU 

Refer to RESUME-(N)ACK 

PDU 


NM <^ BSSGP 1 


NM-FLUSH-LL 




X 


X 




BVCI, NSEI, 

Refer to FLUSH-LL PDU 

Refer to FLUSH-LL-ACK 

PDU 


NM-LLG-DISGARDED 


X 








BVCI, NSEI, 

Refer to LLC-DISCARDED 

PDU 


NM-FLOW-CONTROL- 
BVC 


X 






X 


BVCI, NSEI, 
Refer to FLOW- 
CONTROL-BVC PDU 
Refer to FLOW- 
CONTROL-BVC ACK PDU 


NM-FLOW-CONTROL-MS 


X 






X 


BVCI, NSEI, 
Refer to FLOW- 
CONTROL-MS PDU Refer 
to FLOW-CONTROL-MS 
ACK PDU 
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Generic name 


Ty 


pe 


Parameters 


REQuest 


INDication 


RESponse 


CoNFirm 


NM-FLOW-CONTROL-PFC 


X 






X 


BVCI, NSEI, 
Refer to FLOW- 
CONTROL-PFC PDU 
Refer to FLOW- 
CONTROL-PFC ACK PDU 


NM-STATUS 


X 


X 


- 


- 


BVCI, NSEI, 

Refer to STATUS PDU 


NM-BVC-BLOCK 


X 






X 


BVCI, NSEI, 

Refer to BVC-BLOCK PDU 

Refer to BVC-BLOCK-ACK 

PDU 


NM-BVC-UNBLOCK 


X 






X 


BVCI, NSEI, 

Refer to BVC-UNBLOCK 

PDU 

Refer to BVC-UNBLOCK- 

ACK PDU 


NM-BVC-RESET 


X 


X 


X 


X 


BVCI, NSEI, 

Refer to BVC-RESET PDU 

Refer to BVC-RESET-ACK 

PDU 


NM-TRACE 




X 






BVCI, NSEI, 

Refer to SGSN-INVOKE- 

TRACE PDU 


NW-OVERLOAD 


- 


X 


- 


- 


BVCI, NSEI, 

Refer to OVERLOAD PDU 


PFIM « BSSGP 1 


PFM-DOWNLOAD-BSS- 
PFC 


X 








BVCI, NSEI 

Refer to DOWNLOAD- 

BSS-PFC PDU 


PFM-CREATE-BSS-PFC 




X 


X 




BVCI, NSEI 

Refer to CREATE-BSS- 

PFC PDU 

Refer to CREATE-BSS- 

PFC-ACK PDU 

Refer to CREATE-BSS- 

PFC-NACK PDU 


PFM-MODIFY-BSS-PFC 


X 






X 


BVCI, NSEI 

Refer to MODIFY-BSS- 

PFC PDU 

Refer to MODIFY-BSS- 

PFC-ACK PDU 


PFM-DELETE-BSS-PFC 


X 


X 


X 




BVCI, NSEI 

Refer to DELE 1 b-BSS- 

PFC PDU 

Refer to DELE Ib-BSS- 

PFC-ACK PDU 

Refer to DELETE-BSS- 

PFC-REQ PDU 


PFM-PS-HANDOVER- 
REQUIRED 


X 






X 


BVCI, NSEI, 

Refer to PS-HANDOVER- 

REOUIRED PDU 

Refer to PS-HANDOVER- 

REOUIRED-(N)ACK PDU 


PFM-PS-HANDOVER- 
REQUEST 




X 


X 




BVCI, NSEI, 

Refer to PS-HANDOVER- 

REOUEST PDU 

Refer to PS-HANDOVER- 

REOUEST-(N)ACK PDU 


PFM-PS-HANDOVER- 
COMPLETE 


X 








BVCI, NSEI, 

Refer to PS-HANDOVER- 
COMPLETE PDU 


PFM-PS-HANDOVER- 
CANCEL 


X 








BVCI, NSEI, 

Refer to PS-HANDOVER- 
CANCEL PDU 


LCS <» BSSGP 
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Generic name 


Type 


Parameters 


REQuest 


INDication 


RESponse 


CoNFirm 


LCS-LOCATE 




X 


X 




BVCI, NSEI 

Refer to PERFORM- 

LOCATION-REOUEST 

PDU 

Refer to PERFORM- 

LOCATION-RESPONSE 

PDU 


LCS-ABORT 




X 






BVCI, NSEI 

Refer to PERFORM- 

LOCATION-ABORT PDU 


LCS-INFORMATION- 
TRANSFER 


X 






X 


BVCI, NSEI 
Refer to POSITION- 
COMMAND PDU 
Refer to POSITION- 
RESPONSE PDU 


RIM «> BSSGP 1 


RIM-PDU-TRANSFER 


X 


X 






BVCI, NSEI 

Refer to RAN- 

INFORMATION- 

REOUEST, RAN- 

INFORMATION, RAN- 

INFORMATION-ACK, 

RAN-INFORMATION- 

APPLICATION-ERROR, 

RAN-INFORMATION- 

ERROR PDUs; 


MBMS « BSSGP 1 


MBMS-SESSION-START 




X 


X 




BVCI, NSEI 

Refer to MBMS-SESSION- 
START-REOUEST PDU; 
Refer to MBMS-SESSION- 
START-RESPONSE PDU 


MBMS-SESSION-STOP 




X 


X 




BVCI, NSEI 

Refer to MBMS-SESSION- 
STOP-REQUEST PDU; 
Refer to MBMS-SESSION- 
STOP- RESPONSE PDU 


MBMS-SESSION-UPDATE 




X 


X 




BVCI, NSEI 

Refer to MBMS-SESSION- 

UPDATE-REQUEST PDU; 

Refer to MBMS-SESSION- 

UPDATE-RESPONSE 

PDU 



5.2.1 RL-DL-UNITDATA.ind 

Receipt of a DL-UNITDATA PDU from an SGSN by a BSS containing an LLC -PDU and MS control information 
necessary for the transmission of the LLC-PDU across the radio interface. 

5.2.2 RL-UL-UNITDATA.req 

Request to send a UL-UNITDATA PDU to an SGSN from a BSS containing an LLC-PDU and radio interface derived 
information. 

5.2.3 (void) 

5.2.3a RL-DL-MBMS-UNITDATA.ind 

Receipt of a DL-MBMS-UNITDATA PDU from an SGSN by a BSS containing an LLC-PDU for the transmission of 
the LLC-PDU across the radio interface. 
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5.2.3b RL-UL-MBMS-UNITDATA.req 

Request to send a UL-MBMS-UNITDATA PDU to an SGSN from a BSS containing an LLC-PDU. 

5.2.4 GMM-PAGING.ind 

Receipt of a PAGING-PS or PAGING-CS PDU from an SGSN by a BSS containing instructions to page an MS within 
a given group of cells. 

5.2.5 GMM-RA-CAPABILITY.ind 

Receipt of a RA-CAP ABILITY PDU from an SGSN by a BSS providing the new Radio Access capability of an MS. 

5.2.6 GMM-RA-CAPABILITY-UPDATE.req 

Request to send a RA-CAP ABILITY-UPDATE PDU to an SGSN from a BSS in order to receive the current Radio 
Access capabilities of an MS. 

5.2.7 GMM-RA-CAPABILITY-UPDATE.cnf 

Receipt of a RA-CAP ABILITY-UPD ATE- ACK PDU from a SGSN by a BSS containing the current Radio Access 
capabilities of an MS. 

5.2.8 GMM-RADIO-STATUS.req 

Request to send a RADIO-STATUS PDU to an SGSN from a BSS to report that an exception condition occurred in the 
operation of the radio interface for an MS. 

5.2.9 GMM-SUSPEND.req 

Request to send a SUSPEND PDU to an SGSN from a BSS to mark an MS's GPRS service as suspended. 

5.2.10 GMM-SUSPEND.cnf 

Receipt of a SUSPEND-ACK PDU from an SGSN by a BSS confirming that an SGSN has marked an MS's GPRS 
service as suspended. 

5.2.11 GMM-RESUME.req 

Request to send a RESUME PDU to an SGSN from a BSS to mark an MS's GPRS service as resumed. 

5.2.12 GMM-RESUME.cnf 

Receipt of a RESUME- ACK PDU from an SGSN by a BSS confirming that an SGSN has marked an MS's GPRS 
service as resumed. 

5.2.13 NM-FLUSH-LL.ind 

On receipt of a FLUSH-LL PDU by a BSS from an SGSN, the BSS will either delete queued LLC-PDUs for a TLLI or 
move the queued LLC-PDUs from an old to a new B VC. If there is a BSS context for the Mobile Station identified by 
the TLLI and the BSS is able to move the queued LLC-PDUs, the BSS has to move the BSS context from the old to the 
new BVC, even if it is not able to offer the same QoS characteristics in the new BVC. 
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5.2.14 NM-FLUSH-LL.res 

Sending of a FLUSH-LL-ACK PDU to the SGSN from a BSS to report if queued LLC-PDU(s) for an MS were deleted 
or transferred from the old to the new cell within the routing area. The FLUSH-LL-ACK PDU may also report whether 
the QoS characteristics of the BSS context associated to the MS could be kept in the new cell. 

5.2.15 NM-LLC-DISCARDED.req 

Request to send a LLC-DISCARDED PDU to an SGSN from a BSS indicating that LLC frames pertaining to an MS 
have been locally discarded. 

5.2.16 NM-FLOW-CONTROL-BVC.req 

Request to send a FLOW-CONTROL-BVC PDU to an SGSN from a BSS indicating the ability of a BVC to accept a 
certain flow of data. 

5.2.17 NM-FLOW-CONTROL-BVC.cnf 

Confirmation that a FLOW-CONTROL-BVC PDU has been received by an SGSN for a given BVC. 

5.2.18 NM-FLOW-CONTROL-MS.req 

Request to send a FLOW-CONTROL-MS PDU to an SGSN from a BSS indicating the ability to accept a certain flow 
of data for a given MS. 

5.2.19 NM-FLOW-CONTROL-MS.cnf 

Confirmation that a FLOW-CONTROL-MS PDU has been received by an SGSN for a given MS. 

5.2.19a NM-FLOW-CONTROL-PFC.req 

Request to send a FLOW-CONTROL-PFC PDU to an SGSN from a BSS indicating the ability to accept a certain flow 
of data for a given PFC of a given MS. 

5.2.19b NM-FLOW-CONTROL-PFC.cnf 

Confirmation that a FLOW-CONTROL-PFC PDU has been received by an SGSN for a given PFC of a given MS. 

5.2.20 NM-STATUS.req 

Request to send a STATUS PDU to an SGSN from a BSS to report that an exception condition occurred within the 
BSS. 

5.2.21 NM-STATUS.ind 

Receipt of a STATUS PDU from an SGSN by a BSS indicating that an exception condition occurred within an SGSN. 

5.2.22 NM-BVC-BLOCK.req 

Request to send a BVC-BLOCK PDU to an SGSN from a BSS to mark a BVC as blocked. 

5.2.23 NM-BVC-BLOCK.cnf 

Receipt of a BVC-BLOCK- ACK PDU from an SGSN by a BSS confirming that an SGSN has marked a BVC as 
blocked. 
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5.2.24 NM-BVC-UNBLOCK.req 

Request to send a BVC-UNBLOCK PDU to an SGSN from a BSS to mark a BVC as unblocked. 

5.2.25 NM-BVC-UNBLOCK.cnf 

Receipt of a BVC -UNBLOCK- ACK PDU from an SGSN by a BSS confirming that an SGSN has marked a BVC as 
unblocked. 

5.2.26 NM-BVC-RESET.req 

Request to send a BVC-RESET PDU to an SGSN from a BSS to reset an SGSN's GPRS BVC contexts. 

5.2.27 NM-BVC-RESET.res 

Sending of a BVC-RESET- ACK PDU to the SGSN from an BSS indicating that a GPRS BVC context has been reset in 
the BSS. 

5.2.28 NM-BVC-RESET.ind 

Receipt of a BVC-RESET PDU at a BSS from an SGSN indicating that GPRS BVC contexts have been reset at the 
SGSN. 

5.2.29 NM-BVC-RESET.cnf 

Receipt of a BVC-RESET- ACK PDU at a BSS confirming that GPRS BVC context has been reset at the SGSN. 

5.2.30 NM-TRACE.ind 

Receipt of a SGSN-INVOKE-TRACE PDU at a BSS from an SGSN indicating the need to produce a trace record on an 
MS. 

5.2.30a NW-OVERLOAD.ind 

Receipt of an OVERLOAD PDU from an SGSN by a BSS informing the BSS the SGSN is in an overload state. 

5.2.31 PFM-DOWNLOAD-BSS-PFC.req 

Upon a request to transfer an uplink or downlink LLC PDU for which it currently does not have a BSS Packet Flow 
Context, the BSS may send a DOWNLOAD-BSS-PFC PDU to an SGSN. 

5.2.32 PFM-CREATE-BSS-PFC.ind 

Receipt of a CREATE-BSS-PFC PDU at a BSS from an SGSN indicating that the BSS should create or modify a BSS 
Packet Flow Context using the Aggregate BSS QoS Profile. 

5.2.33 PFM-CREATE-BSS-PFC.res 

Sending of a CREATE-BSS-PFC-ACK PDU to the SGSN from a BSS to respond with an Aggregate BSS QoS Profile, 
indicating queuing or successful creation of the PFC, or a CREATE-BSS-PFC-NACK in case the BSS was unable to 
create the PFC. 

5.2.34 PFM-MODIFY-BSS-PFC.req 

Request to send a MODIFY-BSS-PFC PDU to an SGSN from a BSS to modify an Aggregate BSS QoS Profile. 
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5.2.35 (void) 

5.2.36 (void) 

5.2.37 PFM-MODIFY-BSS-PFC.cnf 

Reception of a MODIFY-BSS-PFC-ACK PDU at a BSS from an SGSN confirming the modification of an Aggregate 
BSS QoS Profile. 

5.2.38 PFM-DELETE-BSS-PFC.ind 

Receipt of a DELETE-BSS-PFC PDU at a BSS from an SGSN to delete an Aggregate BSS QoS Profile. 

5.2.39 PFM-DELETE-BSS-PFC.res 

Sending of a DELETE-BSS-PFC-ACK PDU to an SGSN from a BSS to respond to a deletion. 

5.2.39a PFM-DELETE-BSS-PFC.req 

Sending of a DELETE-BSS-PFC-REQ PDU to an SGSN from a BSS to request to a deletion of an Aggregate BSS QoS 
Profile. 

5.2.39b PFM-PS-HANDOVER-REQUIRED.req 

Request to send a PS -HANDOVER-REQUIRED PDU to the SGSN from the source BSS to initiate the allocation of 
resources in the target system at PS handover. 

5.2.39c PFM-PS-HANDOVER-REQUIRED.cnf 

Receipt of a PS-HANDOVER-REQUIRED-ACK PDU from the SGSN by the source BSS reporting successful 
allocation of resources in the target system at PS handover. 

5.2.39d PFM-PS-HANDOVER-REQUEST.ind 

Receipt of a PS-HANDOVER-REQUEST PDU from the SGSN by the target BSS to initiate the allocation of resources 
for one or more PFCs during PS handover. 

5.2.39e PFM-PS-HANDOVER-REQUEST.res 

Request to send a PS-HANDOVER-REQUEST- ACK PDU to the SGSN from the target BSS to report the successful 
allocation of resources during PS handover. 

5.2.39f PFM-PS-HANDOVER-COMPLETE.req 

Request to send a PS-HANDOVER-COMPLETE PDU to the SGSN from the target BSS to report a successful channel 
change during PS handover. 

5.2.39g PFM-PS-HANDOVER-CANCEL.req 

Request to send a PS-HANDOVER-CANCEL PDU to the SGSN from the source BSS to cancel a previously initiated 
PS handover. 
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5.2.40 LCS-LOCATE.ind 

Receipt of a PERFORM-LOCATION-REQUEST PDU at a BSS from an SGSN requesting a location procedure for a 
target MS. 

5.2.41 LCS-LOCATE.res 

Sending of a PERFORM-LOCATION-RESPONSE PDU to an SGSN responding to the location request for a target 
MS. 

5.2.42 LCS-ABORT.ind 

Receipt of a PERFORM-LOCATION- ABORT PDU at a BSS from an SGSN indicating a request of an abort of a 
location procedure for a target MS. 

5.2.43 LCS-INFORMATION-TRANSFER.req 

Request to send a POSITION-COMMAND PDU to an SGSN from a BSS that has LCS related information associated 
with a higher level protocol available to transfer. 

5.2.44 LCS-INFORMATION-TRANSFER.cnf 

Confirmation in a POSTION-RESPONSE PDU that the higher layer message has been received and an indication of the 
result of the message transfer and possibly including a reply with another higher layer protocol message. 

5.2.45 RIM-PDU-TRANSFER.req 

Sending of a RAN-INFORMATION-REQUEST, RAN-INFORMATION, RAN-INFORMATION-ACK, RAN- 
INFORMATION-APPLICATION-ERROR, RAN-INFORMATION-ERROR PDU to an SGSN from a BSS for routing 
of the PDU to another BSS. 

5.2.46 RIM-PDU-TRANSFER.ind 

Reception of a RAN-INFORMATION-REQUEST, RAN-INFORMATION, RAN-INFORMATION-ACK, RAN- 
INFORMATION-APPLICATION-ERROR, RAN-INFORMATION-ERROR PDU at a BSS from an SGSN originating 
from another BSS. 

5.2.47 (void 

5.2.48 (void 

5.2.49 (void 

5.2.50 (void 

5.2.51 (void 

5.2.52 (void 

5.2.53 MBMS-SESSION-START-REQUEST.ind 

Reception of an MBMS-SESSION-START-REQUEST PDU at a BSS from an SGSN requesting to start an MBMS 
session. 



£75/ 



3GPP TS 48.01 8 version 1 1 .3.0 Release 1 1 28 ETSI TS 1 48 01 8 V1 1 .3.0 (201 3-07) 

5.2.54 MBMS-SESSION-START-RESPONSE.res 

Sending of an MBMS-SESSION-START-RESPONSE PDU to an SGSN from a BSS acknowledging to start an MBMS 
session. 

5.2.55 MBMS-SESSION-STOP-REQUEST.ind 

Reception of an MBMS-SESSION-STOP-REQUEST PDU at a BSS from an SGSN requesting to stop an MBMS 
session. 

5.2.56 MBMS-SESSION-STOP-RESPONSE.res 

Sending of an MBMS-SESSION-STOP-RESPONSE PDU to an SGSN from a BSS acknowledging to stop an MBMS 
session. 

5.2.57 MBMS-SESSION-UPDATE-REQUEST.ind 

Reception of an MBMS-SESSION-UPDATE-REQUEST PDU at a BSS from an SGSN requesting to update the 
MBMS service area list of an ongoing MBMS broadcast service session. 

5.2.58 MBMS-SESSION-UPDATE-RESPONSE.res 

Sending of an MBMS-SESSION-UPDATE-RESPONSE PDU to an SGSN from a BSS acknowledging to update the 
MBMS service area list of an ongoing MBMS broadcast service session. 

5.3 Service primitives provided by the BSSGP at an SGSN 

Table 5.3: Service primitives provided by BSSGP at an SGSN 



Generic name 



Type 



REQuest I INDication | RESponse | CoNFirm 



Parameters 
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Generic name 


Type 


Parameters 


REQuest 1 INDication 1 RESponse 1 CoNFIrm 


LL «> BSSGP 1 


BSSGP-DL-UNITDATA 


X 








BVCI, NSEI, LSP, 
Refer to DL-UNITDATA 
PDU 


BSSGP-UL-UNITDATA 




X 






BVCI, NSEI, 

Refer to UL-UNITDATA 

PDU 


BSSGP-DL-MBMS- 
UNITDATA 


X 








BVCI, NSEI, 
Refer to DL-MBMS- 
UNITDATA PDU 


BSSGP-UL-MBMS- 
UNITDATA 




X 






BVCI, NSEI, 
Refer to UL-MBMS- 
UNITDATA PDU 


GMIM <» BSSGP 1 


GMM-PAGING 


X 








BVCI, NSEI, 

Refer to PAGING PS PDU 

Refer to PAGING CS PDU 


GMM-RA-CAPABILITY 


X 








BVCI, NSEI, 

Refer to RA-CAPABILITY 

PDU 


GMM-RA-CAPABILITY- 
UPDATE 




X 


X 




BVCI, NSEI, 

Refer to RA-CAPABILITY- 

UPDATE PDU, 

Refer to RA-CAPABILITY- 

UPDATE-ACK PDU 


GMM-RADIO-STATUS 




X 






BVCI, NSEI, 

Refer to RADIO-STATUS 

PDU 


GMM-SUSPEND 




X 






BVCI, NSEI, 

Refer to SUSPEND PDU 

Refer to SUSPEND-(N)ACK 

PDU 


GMM-RESUME 




X 






BVCI, NSEI, 

Referto RESUME PDU 

Refer to RESUME-{N)ACK 

PDU 


NM -» BSSGP 1 


NM-FLUSH-LL 


X 






X 


BVCI, NSEI, 

Refer to FLUSH-LL PDU 

Refer to FLUSH-LL-ACK 

PDU 


NM-LLC-DISCARDED 




X 






BVCI, NSEI, 

Refer to LLC-DISCARDED 

PDU 


NM-FLOW-CONTROL- 
BVC 




X 






BVCI, NSEI, 

Refer to FLOW-CONTROL- 
BVC PDU Refer to FLOW- 
CONTROL-BVC ACK PDU 


NM-FLOW-CONTROL- 
MS 




X 






BVCI, NSEI, 

Refer to FLOW-CONTROL- 
MS PDU Refer to FLOW- 
CONTROL-MS ACK PDU 


NM-FLOW-CONTROL- 
PFC 




X 






BVCI, NSEI, 

Refer to FLOW-CONTROL- 
PFCPDU Refer to FLOW- 
CONTROL-PFC ACK PDU 


NM-STATUS 


X 


X 


- 


- 


BVCI, NSEI, 

Refer to STATUS PDU 


NM-BVC-BLOCK 




X 






BVCI, NSEI, 

Refer to BVC-BLOCK PDU 

Refer to BVC-BLOCK-ACK 

PDU 
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Generic name 


Type 


Parameters 


REQuest 


INDication 


RESponse 


CoNFIrm 


NM-BVC-UNBLOCK 




X 






BVCI, NSEI, 

Refer to BVC-UNBLOCK 

PDU 

Refer to BVC-UNBLOCK- 

ACK PDU 


NM-BVC-RESET 


X 


X 


X 


X 


BVCI, NSEI, 

Refer to BVC-RESET PDU 

Refer to BVC-RESET-ACK 

PDU 


NM-TRACE 


X 








BVCI, NSEI, 

Refer to SGSN-INVOKE- 

TRACE PDU 


NW-OVERLOAD 


X 


- 


- 


- 


BVCI, NSEI, 

Refer to OVERLOAD PDU 


PFIVI « BSSGP 1 


PFM-DOWNLOAD-BSS- 
PFC 




X 






BVCI, NSEI 

Refer to DOWNLOAD-BSS- 

PFC PDU 


PFM-CREATE-BSS-PFC 


X 






X 


BVCI, NSEI 

Refer to CREATE-BSS-PFC 

PDU 

Refer to CREATE-BSS- 

PFC-ACK PDU 

Refer to CREATE-BSS- 

PFC-NACK PDU 


PFM-MODIFY-BSS-PFC 




X 


X 




BVCI, NSEI 

Refer to MODIFY-BSS-PFC 

PDU 

Refer to MODIFY-BSS- 

PFC-ACK PDU 


PFM-DELETE-BSS-PFC 


X 


X 




X 


BVCI, NSEI 

Refer to DELETE-BSS-PFC 

PDU 

Refer to DELETE-BSS- 

PFC-ACK PDU 

Refer to to DELETE-BSS- 

PFC-REO PDU 


PFM-PS-HANDOVER- 
REQUIRED 




X 


X 




BVCI, NSEI, 

Refer to PS-HANDOVER- 

REOUIRED PDU 

Refer to PS-HANDOVER- 

REOUIRED-(N)ACK PDU 


PFM-PS-HANDOVER- 
REQUEST 


X 






X 


BVCI, NSEI, 

Refer to PS-HANDOVER- 

REOUEST PDU 

Refer to PS-HANDOVER- 

REOUEST-(N)ACK PDU 


PFM-PS-HANDOVER- 
COMPLETE 




X 






BVCI, NSEI, 

Refer to PS-HANDOVER- 
COMPLETE PDU 


PFM-PS-HANDOVER- 
CANCEL 




X 






BVCI, NSEI, 

Refer to PS-HANDOVER- 
CANCEL PDU 


LCS » BSSGP 1 


LCS-LOCATE 


X 






X 


BVCI, NSEI 

Refer to PERFORM- 

LOCATION-REOUEST 

PDU 

Refer to PERFORM- 

LOCATION-RESPONSE 

PDU 


LCS-ABORT 


X 








BVCI, NSEI 

Refer to PERFORM- 

LOCATION-ABORT PDU 
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Generic name 


Type 


Parameters 


REQuest 


INDication 


RESponse 


CoNFIrm 


LCS-INFORMATION- 
TRANSFER 




X 


X 




BVCI, NSEI 
Refer to POSITION- 
COMMAND PDU 
Refer to POSITION- 
RESPONSE PDU 


RIM » BSSGP 1 


RIM-PDU-TRANSFER 


X 


X 






BVCI, NSEI 
Refer to RAN- 
INFORMATION-REQUEST, 
RAN-INFORMATION, RAN- 
INFORMATION-ACK, RAN- 
INFORMATION- 
APPLICATION-ERROR, 
RAN-INFORMATION- 
ERROR PDUs; 


MBMS » BSSGP 1 


MBMS-SESSION-START 


X 






X 


BVCI, NSEI 

Refer to MBMS-SESSION- 
START-REOUEST PDU; 
Refer to MBMS-SESSION- 
START-RESPONSE PDU 


MBMS-SESSION-STOP 


X 






X 


BVCI, NSEI 

Refer to MBMS-SESSION- 
STOP-REQUEST PDU; 
Refer to MBMS-SESSION- 
STOP- RESPONSE PDU 


MBMS-SESSION- 
UPDATE 


X 






X 


BVCI, NSEI 

Refer to MBMS-SESSION- 
UPDATE-REQUEST PDU; 
Refer to MBMS-SESSION- 
UPDATE-RESPONSE PDU 



NOTE: The parameters in the BSSGP -DL-UNITDATA and BSSGP -UL-UNITDATA primitives that are not 
included in the corresponding primitives in 3GPP TS 44.064 are provided or extracted by some 
intermediate function out of the scope of the present document. 

5.3.1 BSSGP-DL-UNITDATA.req 

Request to send a DL-UNITDATA PDU to a BSS from an SGSN containing an LLC-PDU and control information 
necessary for the transmission of the LLC-PDU across the radio interface. 

5.3.2 BSSGP-UL-UNITDATA.ind 

Receipt of a UL-UNITDATA PDU from a BSS by an SGSN containing an LLC-PDU and radio interface derived 
information. 

5.3.3 (void) 

5.3.3a BSSGP-DL-MBMS-UNITDATA.req 

Request to send a DL-MBMS-UNITDATA PDU to a BSS from an SGSN containing an LLC-PDU for the transmission 
of the LLC-PDU across the radio interface. 

5.3.3b BSSGP-UL-MBMS-UNITDATA.ind 

Receipt of a UL-MBMS-UNITDATA PDU from a BSS by an SGSN containing an LLC-PDU. 
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5.3.4 GMM-PAGING.req 

Request to send a PAGING-PS or PAGING-CS PDU from an SGSN to a BSS containing instructions to page an MS 
within a given group of cells. 

5.3.5 GMM-RA-CAPABILITY.req 

Request to send a RA-CAP ABILITY PDU to the BSS from an SGSN containing the Radio Access capability of an MS. 

5.3.6 GMM-RA-CAPABILITY-UPDATE.ind 

Receipt of a RA-CAP ABILITY-UPDATE PDU from a BSS by an SGSN, requesting that the SGSN sends the Radio 
Access capability of an MS to the BSS. 

5.3.7 GMM-RA-CAPABILITY-UPDATE.res 

Sending of a RA-CAP ABILITY-UPDATE- ACK PDU to the BSS from an SGSN containing the current Radio Access 
capability of an MS. 

5.3.8 GMM-RADIO-STATUS.ind 

Receipt of a RADIO-STATUS PDU from a BSS by an SGSN to report that an exception condition occurred in the 
operation of the radio interface for an MS. 

5.3.9 GMM-SUSPEND.ind 

Receipt of a SUSPEND PDU from a BSS by an SGSN indicating that an MS wishes to suspended its GPRS service. 

5.3.10 GMM-RESUME.ind 

Receipt of a RESUME PDU from a BSS by an SGSN indicating that an MS wishes to resume its GPRS service. 

5.3.11 NM-FLUSH-LL.req 

Request to send a FLUSH-LL PDU from an SGSN to a BSS, instructing the BSS to either delete queued LLC-PDUs for 
a TLLI or move the queued LLC-PDUs from an old to a new BVC. 

5.3.12 NM-FLUSH-LLcnf 

Receipt of a FLUSH-LL- ACK PDU at an SGSN informing if the queued LLC-PDU(s) for an MS were deleted or 
transferred from the old to the new cell within the routing area. The FLUSH-LL-ACK PDU may also report whether the 
QoS characteristics of the BSS context associated to the MS could be kept in the new cell. 

5.3.13 NM-LLC-DISCARDED.ind 

Receipt of a LLC -DISCARDED PDU from a BSS by an SGSN indicating that LLC frames pertaining to an MS have 
been locally discarded. 

5.3.14 NM-FLOW-CONTROL-BVC.ind 

Receipt of a FLOW-CONTROL-BVC PDU from a BSS by an SGSN indicating the ability of a BVC to accept a certain 
flow of data. 
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5.3.15 NM-FLOW-CONTROL-MS.ind 

Receipt of a FLOW-CONTROL-MS PDU from a BSS by an SGSN indicating the ability to accept a certain flow of 
data for a given MS. 

5.3.15a NM-FLOW-CONTROL-PFC.ind 

Receipt of a FLOW-CONTROL-PFC PDU from a BSS by an SGSN indicating the abihty to accept a certain flow of 
data for a given PFC of a given MS. 

5.3.16 NM-STATUS.req 

Request to send a STATUS PDU to a BSS from an SGSN to report that an exception condition occurred within an 
SGSN. 

5.3.17 NM-STATUS.ind 

Receipt of a STATUS PDU from a BSS by an SGSN indicating an exception condition occurred within the BSS. 

5.3.18 NM-BVC-BLOCK.ind 

Receipt of a B VC-BLOCK PDU from a BSS by an SGSN indicating that a B VC shall be marked as blocked. 

5.3.19 NM-BVC-UNBLOCK.ind 

Receipt of a BVC-UNBLOCK PDU from a BSS by an SGSN indicating that a BVC shall be marked as unblocked. 

5.3.20 NM-BVC-RESET.req 

Request to send a BVC-RESET PDU to a BSS from an SGSN to reset a BSS's GPRS BVC contexts. 

5.3.21 NM-BVC-RESET.res 

Sending of a BVC-RESET- ACK PDU to the BSS from a SGSN indicating that a GPRS BVC context has been reset in 
the SGSN. 

5.3.22 NM-BVC-RESET.ind 

Receipt of a BVC-RESET PDU at an SGSN from a BSS indicating that GPRS BVC contexts have been reset at the 
BSS. 

5.3.23 NM-BVC-RESET.cnf 

Receipt of a BVC-RESET-ACK PDU at an SGSN conflrming that GPRS BVC contexts have been reset at the BSS. 

5.3.24 NM-TRACE.req 

Request to send an SGSN-INVOKE-TRACE PDU to a BSS from an SGSN to begin producing a trace record on an MS. 



5.3.24a NM-OVERLOAD-START.req 



Request to send an OVERLOAD PDU to a BSS from an SGSN to inform the BSS an overload situation happened in the 
SGSN. 
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5.3.25 PFM-DOWNLOAD-BSS-PFC.ind 

Receipt of a DOWNLOAD-BSS-PFC PDU at an SGSN from a BSS. 

5.3.26 PFM-CREATE-BSS-PFC.req 

Sending of a CREATE-BSS-PFC PDU to a BSS from an SGSN requesting that the BSS should create or modify a BSS 
Packet Flow Context using the Aggregate BSS QoS Profile. 

5.3.27 PFM-CREATE-BSS-PFC.cnf 

Receipt of a CREATE-BSS-PFC-ACK PDU at an SGSN from a BSS confirming the creation or modification or 
queuing of a BSS Packet Flow Context using the Aggregate BSS QoS Profile or a CREATE-BSS-PFC -NACK in to 
indicate the BSS was unable to create the PEC. 

5.3.28 PFM-MODIFY-BSS-PFC.ind 

Receipt of a MODIFY-BSS-PFC PDU at an SGSN from a BSS to modify an Aggregate BSS QoS Profile. 

5.3.29 PFM-MODIFY-BSS-PFC.res 

Sending of a MODIFY-BSS-PFC-ACK PDU to a BSS from an SGSN to respond with an Aggregate BSS QoS Profile. 

5.3.30 PFM-DELETE-BSS-PFC.req 

Sending of a DELETE-BSS-PFC PDU to a BSS from an SGSN to delete an Aggregate BSS QoS Profile. 

5.3.31 PFM-DELETE-BSS-PFC.cnf 

Receipt of a DELETE-BSS-PFC-ACK PDU at an SGSN from a BSS to confirm the deletion of an Aggregate BSS QoS 
Profile. 

5.3.31a PFM-DELETE-BSS-PFC.ind 

Receipt of a DELETE-BSS-PFC-REQ PDU at an SGSN from a BSS that a deletion of an Aggregate BSS QoS Profile is 
requested. 

5.3.31 b PFM-PS-HANDOVER-REQUIRED.ind 

Receipt of a PS-HANDOVER-REQUIRED PDU from the source BSS by the SGSN indicating initiation of a PS 
handover. 

5.3.31 c PFM-PS-HANDOVER-REQUIRED.res 

Request to send a PS-HANDOVER-REQUIRED-ACK PDU from the SGSN to the source BSS to initiate the channel 
change attempt during PS handover. 

5.3.31 d PFM-PS-HANDOVER-REQUEST.req 

Request to send a PS-HANDOVER-REQUEST PDU from the SGSN to the target BSS to initiate the allocation of 
resources for one or more PFCs during PS handover. 

5.3.31 e PFM-PS-HANDOVER-REQUEST.cnf 

Receipt of a PS-HANDOVER-REQUEST- ACK PDU from the target BSS by the SGSN reporting the successful 
allocation of resources during PS handover. 
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5.3.31f PFM-PS-HANDOVER-COMPLETE.ind 

Receipt of a PS -HANDOVER-COMPLETE PDU from the target BSS by the SGSN reporting a successful channel 
change during PS handover. 

5.3.31 g PFM-PS-HANDOVER-CANCEL.ind 

Receipt of a PS -HANDOVER-CANCEL PDU from the source BSS by the SGSN indicating cancellation of a 
previously initiated PS handover. 

5.3.32 LCS-LOCATE.req 

Sending of a PERFORM-LOCATION-REQUEST PDU at an SGSN requesting a location procedure for a target MS. 

5.3.33 LCS-LOCATE.cnf 

Receipt of a PERFORM-LOCATION-RESPONSE PDU confirming that the location request for a target MS has been 
attempted indicating the result of this attempt. 

5.3.34 LCS-ABORT.req 

Sending of a PERFORM-LOCATION-ABORT PDU from an SGSN to a BSS requesting an abort of a location 
procedure for a target MS. 

5.3.35 LCS-INFORMATION-TRANSFER.ind 

Receipt of a POSITION-COMMAND PDU at an SGSN from a BSS requesting a transfer of a higher level protocol 

message. 

5.3.36 LCS-INFORMATION-TRANSFER.res 

Sending of a POSITION-RESPONSE PDU from an SGSN to a BSS indicating the result of the message transfer and 
possibly including the transfer of a new higher layer protocol message. 

5.3.37 RIM-PDU-TRANSFER.req 

Sending of a RAN-INFORMATION-REQUEST, RAN-INFORMATION, RAN-INFORMATION-ACK, RAN- 
INFORMATION-APPLICATION-ERROR, RAN-INFORMATION-ERROR PDU to a BSS from an SGSN. 

5.3.38 RIM-PDU-TRANSFER.ind 

Reception of a RAN-INFORMATION-REQUEST, RAN-INFORMATION, RAN-INFORMATION-ACK, RAN- 
INFORMATION-APPLICATION-ERROR, RAN-INFORMATION-ERROR PDU at an SGSN from a BSS for routing 
of the PDU to another BSS. 
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5.3.39 (void) 

5.3.40 (void) 

5.3.41 (void) 

5.3.42 (void) 

5.3.43 (void) 

5.3.44 (void) 

5.3.45 MBMS-SESSION-START-REQUEST.req 

Sending of an MBMS-SESSION-START-REQUEST PDU to a BSS from an SGSN requesting to start an MBMS 
session. 

5.3.46 MBMS-SESSION-START-RESPONSE.cnf 

Receipt of an MBMS-SESSION-START-RESPONSE PDU from a BSS acknowledging to start an MBMS session. 

5.3.47 MBMS-SESSION-STOP-REQUEST.req 

Sending of an MBMS-SESSION-STOP-REQUEST PDU to a BSS from an SGSN requesting to stop an MBMS 
session. 

5.3.48 MBMS-SESSION-STOP-RESPONSE.cnf 

Receipt of an MBMS-SESSION-STOP-RESPONSE PDU from a BSS acknowledging to stop an MBMS session. 

5.3.49 MBMS-SESSION-UPDATE-REQUEST.req 

Sending of an MBMS-SESSION-UPDATE-REQUEST PDU to a BSS from an SGSN requesting to update the MBMS 
service area list of an ongoing MBMS broadcast service session. 

5.3.50 MBMS-SESSION-UPDATE-RESPONSE.cnf 

Receipt of an MBMS-SESSION-UPDATE-RESPONSE PDU from a BSS acknowledging to update the MBMS service 
area list of an ongoing MBMS broadcast service session. 

5.4 Primitive parameters 

5.4.1 BSSGP Virtual Connection Identifier (BVCI) 

BSSGP Virtual Connections (BVCs) provide communication paths between BSSGP entities. Each BVC is used in the 
transport of BSSGP PDUs between peer point-to-point (PTP) functional entities, peer point-to-multipoint (PTM) 
functional entities and peer signalling functional entities. Table 5.4.1 lists the mapping of the BSSGP PDU to the 
associated functional entity and the BVCI. The BVCI is used to enable the lower network service layer to efficiently 
route the BSSGP PDU to the peer entity. This parameter is not part of the BSSGP PDU across the Gb interface, but is 
used by the network service entity across the Gb. 
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Any BSSGP PDU received by the BSS or the SGSN containing a PDU type that does not fit, according to the mapping 
defined in table 5.4.1, with the functional entity identified by the BVCI provided by the network service entity, is 
discarded and a STATUS PDU with a cause value set to "Protocol error - unspecified" is sent. 

A PTP functional entity is responsible for PTP user data transmission. There is one PTP functional entity per cell. 
Within the present document, a cell is identified by a BVCI unless it is explicitly stated otherwise. 

A PTM functional entity is responsible for PTM user data transmission. There is one or more PTM functional entities 
per BSS. 

A signalling functional entity is responsible for other functions e.g. paging. There is only one signalling entity per 
Network Service Entity (NSE). There is one or more NSEs per BSS. 

Each B VC is identified by means of a BSSGP Virtual Connection Identifier (BVCI) which has end-to-end significance 
across the Gb interface. Each BVCI is unique between two peer Network Service Entities. 

In the BSS, it shall be possible to configure BVCIs statically by administrative means, or dynamically. In case of 
dynamic configuration, the BSSGP shall accept any BVCI passed by the underlying Network Service entity. 

At the SGSN side, BVCIs associated with PTP functional entities shall be dynamically configured. The BVCIs 
associated with signalling functional entities and PTM functional entities are statically configured. 

The BVCI value 0000 hex shall be used for the signalling functional entities. 

The BVCI value 0001 hex shall be used for the PTM functional entities. 

All other values may be used freely by the BSS and shall be accepted by the SGSN. 

Table 5.4.1 : BSSGP PDU, BVCI and functional entity mapping 
I BSSGP PDU I Mapping of BVCI to functional entity | 
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DL-UNITDATA 


PTP 


UL-UNITDATA 


PTP 


RA-CAPABILITY 


PTP 


DL-MBMS-UNITDATA 


PTM 


UL-MBMS-UNITDATA 


PTM 


PAGING-PS 


PTP or SIGNALLING (note 1) 


PAGING-CS 


PTP or SIGNALLING (note 2) 


RA-GAPABILITY-UPDATE / RA-GAPABILITY-UPDATE-AGK 


PTP 


RADIO-STATUS 


PTP 


SUSPEND / SUSPEND-AGK / SUSPEND-NAGK 


SIGNALLING 


RESUME / RESUME-AGK / RESUME-NAGK 


SIGNALLING 


FLUSH-LL / FLUSH-LL-AGK 


SIGNALLING 


LLG-DISCARDED 


SIGNALLING 


FLOW-GONTROL-BVG / FLOW-GONTROL-BVG-ACK 


PTP 


FLOW-GONTROL-MS / FLOW-GONTROL-MS-AGK 


PTP 


FLOW-GONTROL-PFG / FLOW-GONTROL-PFG-AGK 


PTP 


STATUS 


PTP or PTM or SIGNALLING (note 3) 


BVG-BLOGK / BVG-BLOGK-AGK 


SIGNALLING 


BVG-UNBLOGK / BVG-UNBLOGK-AGK 


SIGNALLING 


BVG-RESET/ BVG-RESET-AGK 


SIGNALLING 


SGSN-INVOKE-TRAGE 


SIGNALLING 


DOWNLOAD-BSS-PFG 


PTP 


GREATE-BSS-PFG / GREATE-BSS-PFG-AGK / GREATE-BSS- 
PFG-NAGK 


PTP 


MODIFY-BSS-PFG / MODIFY-BSS-PFG-AGK 


PTP 


DELETE-BSS-PFG / DELETE-BSS-PFG-AGK / DELETE-BSS- 
PFG-REQ 


PTP 


PS-HANDOVER-REQUIRED / PS-HANDOVER-REQUIRED-AGK 
/ PS-HANDOVER-REQUIRED-NAGK 


PTP 


PS-HANDOVER-REQUEST / PS-HANDOVER-REQUEST-AGK / 
PS-HANDOVER-REQUEST-NAGK 


PTP 


PS-HANDOVER-GOMPLETE/PS-HANDOVER-GOMPLETE-AGK 


PTP 


PS-HANDOVER-GANGEL 


PTP 


PERFORM-LOGATION-REQUEST / PERFORM-LOGATION- 
RESPONSE / PERFORM-LOGATION-ABORT 


SIGNALLING 


POSITION-GOMMAND / POSITION-RESPONSE 


SIGNALLING 


RAN-INFORMATION-REQUEST/ RAN-INFORMATION/ RAN- 
INFORMATION-AGK/ RAN-INFORMATION-ERROR/ RAN- 
INFORMATION-APPLIGATION-ERROR 


SIGNALLING 


MBMS-SESSION-START-REQUEST/MBMS-SESSION-START- 
RESPONSE/ MBMS-SESSION-STOP-REQUEST/ MBMS- 
SESSION-STOP-RESPONSE/MBMS-SESSION-UPDATE- 
REQUEST/MBMS-SESSION-UPDATE-RESPONSE 


SIGNALLING 


NOTE 1 : The network may initiate paging of an IVIS in READY mobility management state at an indication of a lower 
layer failure (see 3GPP TS 24.008 sub-clause 4.7.9.1 ). In this case, the BVGI=PTP may be used. 

NOTE 2: If the network initiates circuit-switched paging of a IVIS in READY mobility management state (e.g. a IVIS in 
class A or B mode of operation and in packet transfer mode), then the BVGI=PTP. If the MS is in STANDBY 
state, then the BVGI=SIGNALLING. 

NOTE 3: The setting of the BVGI is dependent upon the context within which the STATUS PDU was generated. 



5.4.2 Link Selector Parameter (LSP) 



The link selector parameter is defined in 3GPP TS 48.016. At one side of the Gb interface, all BSSGP UNITDATA 
PDUs related to an MS shall be passed with the same LSP, e.g. the LSP contains the MS's TLLI, to the underlying 
network service. The LSPs used at the BSS and SGSN for the same MS may be set to different values. 



5.4.3 [functional-name] PDU 



The parameters that make up a [functional-name] PDU are defined in clause 10, "PDU Functional Definitions and 
contents". 
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5.4.4 Network Service Entity Identifier (NSEI) 

The Network Service Entity at the BSS and the SGSN provides the network management functionality required for the 
operation of the Gb interface. The Network Service Entity is described in 3GPP TS 48.016. 

Each Network Service Entity is identified by means of a Network Service Entity Identifier (NSEI). The NSEI together 
with the BVCI uniquely identifies a BSGP Virtual Connection (e.g. a FTP functional entity) within an SGSN. The NSEI 
is used by the BSS and the SGSN to determine the NS-VCs that provides service to a BVCI. 

5.4.5 BSS Context 

The SGSN can provide a BSS with information related to ongoing user data transmission. The information related to 
one MS is stored in a BSS context. The BSS may contain BSS contexts for several MSs. A BSS context contains a 
number of BSS packet flow contexts. A BSS packet flow context is identified by a packet flow identifier assigned by 
the SGSN. There are four pre-defined packet flows identified by four reserved packet flow identifier values. One 
pre-defined packet flow is used for best-effort service, one for signalling, one for SMS, and one for TOMS. The BSS 
shall not negotiate BSS packet flow contexts for these pre-defined packet flows with the SGSN. 

NOTE: The TOMS PFI is used to transfer LCS RRLP messages between the MS and the SGSN. 

NOTE: PFC procedures (Create BSS PFC, Modify BSS PFC, Delete BSS PFC) and PS Handover procedures (PS 
Handover Required, PS Handover Request, PS Handover Complete) do not apply to pre-defined packet 
flows. 

5.4.6 MBMS Service Context 

The SGSN can provide a BSS with information related to ongoing MBMS user data transmission. The information 
related to one MBMS Session is stored in an MBMS Service Context. A TMGI and optionally an MBMS Session 
Identity identify an MBMS Service Context. The BSS may contain MBMS Service Contexts for several MBMS 
Sessions. 

5.4.7 TLLI 

The TLLI is used to uniquely identify a mobile station and needs to be included in a number of BSSGP PDUs across the 
Gb interface. 

A change of TLLI may occur as a consequence of a P-TMSI reallocation. The new TLLI shall be used to address the 
mobile station after completion on the network side of the related GMM procedure (see 3GPP TS 24.00S). However, 
the SGSN should not use the new TLLI for BSSGP addressing purposes towards the BSS either: 

until having signalled the change of TLLI to the BSS via the Downlink UNITDATA procedure (see sub-clause 
6.1) or 

until having received from the BSS any BSSGP PDU including the new TLLI. 



User data and signalling procedures between RL and 
BSSGP SAPs 



6.1 Downlink UNITDATA procedure 



On the downlink, a DL-UNITDATA PDU shall contain information elements to be used by the RLC/MAC function and 
an LLC -PDU. There shall be only one LLC -PDU per DL-UNITDATA PDU. The LLC-PDU shall always be the last 
information element in the DL-UNITDATA PDU, and shall be aligned on a 32 bit boundary for efficient processing. 

An SGSN provides the BSSGP with a current TLLI, identifying the MS. If an SGSN provides a second TLLI, 
indicating that an MS has recently changed its TLLI, this shall be considered as the "old" TLLI. A BSS uses the "old" 
TLLI to locate an MS's existing context. Subsequent uplink data transfers for this MS shall reference the current TLLI, 
and not the old TLLI. 
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The SGSN shall include the IMSI in the PDU. As an exception, the SGSN may omit the IMSI in the PDU if the mobile 
station identified by the TLLl is in MM non-DRX mode period (i.e. during a GMM procedure for GPRS attach or 
routing area updating defined in 3GPP TS 24.008) and the SGSN does not have a valid IMSI. 

The SGSN may include the Service UTRAN CCO (Cell Change Order) information element in the PDU (relevant if the 
network initiated cell change order to UTRAN, network initiated cell change order to E-UTRAN, PS handover to 
UTRAN or PS handover to E-UTRAN procedures are used ). If this information element is received in multiple PDUs 
(either DL-UNITDATA PDU(s), CREATE-BSS-PFC PDU(s) or PS-HANDOVER-REQUEST PDU(s)), the 
information element contained in the last received PDU shall take precedence. 

If the SGSN has valid DRX Parameters for a TLLI, then the SGSN shall include them in the PDU. Nevertheless, the 
SGSN can omit the DRX Parameters if the MS identified with the TLLI is in MM non-DRX mode period to speed up 
the transmission of the LLC -PDU on the radio interface. The SGSN shall not send a DL-UNITDATA PDU without the 
DRX Parameters IE if the MS identified with the TLLI is not in MM non-DRX mode period. 

An SGSN provides the BSSGP with MS specific information, enabling the RLC/MAC entity in a BSS to transmit an 
LLC -PDU to the MS in a user specific manner. The information made available to the radio interface includes: 

MS Radio Access Capability. This defines the radio capabilities of the ME. If there is valid MS Radio Access 
Capability information known by the SGSN for the associated MS, the SGSN shall include it in the 
DL-UNITDATA PDU. Otherwise, MS Radio Access Capability shall not be present; 

Packet Flow Identifier. This identifies the packet flow context associated with the LLC PDU and is included by 
the SGSN if the packet flow context feature is negotiated. If the mobile station does not support the PFC feature 
or if the PFI is not known (e.g. the new SGSN did not get the PFI from the old SGSN during a RAU) then the 
SGSN shall use the pre-defined PFI to indicate best-effort QoS; 

QoS Profile. This defines the (peak) bit rate, the type of BSSGP's SDU (signalling or data), the type of LLC 
frame (ACK, SACK, or not), the precedence class, and the transmission mode to be used when transmitting the 
LLC-PDU across the radio interface; 

PDU Lifetime. This defines the remaining time period that the PDU is considered as valid within the BSS. If the 
PDU is held for a period exceeding the "PDU Lifetime" time period, the PDU shall be locally discarded. The 
PDU Lifetime is set within the SGSN by the upper layers. 

A BSS may incorporate the PDU Lifetime, the Precedence and the (peak) bit rate into its radio resource scheduler. If the 
PFI is present then the BSS may incorporate the information from the associated ABQP into its radio resource 
scheduler. The algorithm to do this is out of scope of the present document. 

If the PFI is known in the BSS and does not correspond to a predefined PFI, then: 

the (peak) bit rate and the precedence class fields present in the QoS Profile IE shall be ignored by the BSS; 

if the Allocation/Retention Priority was provided at the time the corresponding PFC was created or last modified, 
then the "Priority" IE, if present in the downlink UNITDATA PDU, is discarded. 

Two types of BSSGP SDU are distinguished within the QoS Profile: layer 3 signalling and data. Layer 3 signalling may 
be transmitted over the Um interface with higher protection. If the MS has an RR connection to the network (see 
3GPP TS 44.018), Layer 3 signalling may be transmitted over the Um interface on the main signalling link of the RR 
connection, provided that the LLC PDU meets length restrictions imposed by the BSS. In this case, the BSS shall 
include the LLC PDU contained in the BSSGP PDU in the correspondent Layer 3 Um interface message (see 
3GPPTS 44.018). 

The type of LLC frame indicates if the LLC frame type is an ACK or SACK command/response, or not (see 

3GPP TS 44.064). An ACK or SACK command/response frame type may be transmitted over the Um interface with 

higher protection. 

Two transmission modes across the radio interface are possible: acknowledged (using RLC/MAC ARQ functionality) 
and unacknowledged (using RLC/MAC unitdata functionality). These transmission modes do not apply when the MS 
has an RR connection to the network and BSS uses the main signalling link of the RR connection, in which case the 
acknowledged transmission mode is used. 

If Priority is present, assuming it shall not be discarded according to the rule above, only the priority-level field shall be 
regarded. The management of priority levels is implementation dependent and under operator control. The preemption 
capability indicator, the queuing allowed indicator and preemption vulnerability indicator shall be ignored in this case. 
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In addition to constructing the DL-UNITDATA, the SGSN supplies the LSP, the BVCI, the NSEI, and for an IP sub- 
network the NS Change IP endpoint, associated with the MS to the lower layer network service, enabling network 
service routeing to the peer entity. These parameters are not transmitted as part of the BSSGP across the Gb-interface 
for the purpose of identifying the receiving endpoint (they are sent in the BSSGP Perform-Location-Request PDU to 
identify the serving cell of the target MS). 

If the Gb-interface is supported using an IP sub-network, then the Resource Distribution function at the SGSN may 
transmit a BSSGP DL-UNITDATA PDU with an LLC-PDU Length Indicator set to 0. The BSS uses this 
DL-UNITDATA to change the IP endpoint at the SGSN to which any future UL-UNITDATA for the TLLI (indicated 
in the DL-UNITDATA) is sent. The LLC-PDU with a Length Indicator set to is not sent across the radio interface. 

In the case where localised service area is supported the SGSN may inform the BSS as to which LSA identities that the 
mobile has preferences by sending the LSA INFORMATION element. The BSS stores this information and uses it 
e.g. for network controlled cell re-selection when determining specific cell selection parameters for the mobile. The 
algorithm for determining specific cell selection parameters for the mobile is not defined further in the present 
document. The SGSN may inform the BSS about the contents of SPID in the DL-UNITDATA PDU. In this case the 
SPID is stored in the BSS. 

When the 'Service Identification for improved Radio Utilization for GERAN' (SIRUG) feature (see clause 5.3.5.3 of TS 
23.060 [7]) is supported, and the SGSN receives SCI information in the GTP-U header, the SGSN inserts the SCI IE 
and the GGSN/P-GW location IE in the associated DL-UNITDATA PDU(s). The BSS uses the Home PLMN ID 
contained within the IMSI and the GGSN/P-GW location information to determine whether or not it can handle the SCI 
information for that GGSN/P-GW. If it cannot, the BSS discards the SCI information and shall treat the rest of the DL- 
UNITDATA normally. 

In abnormal cases, if the SCI IE is received but the GGSN/P-GW location IE is missing, then the BSS shall assume that 
the GGSN/P-GW is located in the VPLMN; and, if the GGSN/P-GW location IE is received but the SCI IE is missing, 
then the BSS shall ignore the GGSN/P-GW location IE. 

Specific handling related to MOCN configuration of network sharing, is described in sub-clause 6.6. 

When the SGSN is using a GWCN configuration, and the BSSGP DL-UNITDATA PDU contains a local TLLI, then 
the BSC shall use the TLLI sub-ranges to identify the corresponding serving PLMN. 

6.1.1 Abnormal conditions 

The following actions are defined in periods of congestion. 

To satisfy the maximum number of service requests, the BSS may redistribute MSs among cells (i.e. network controlled 
cell reselection is initiated). If this occurs, the BSS may inform the SGSN through the RADIO-STATUS PDU (Radio 
Cause value: cell reselection ordered). The BSS shall update any internal references that indicate the location of the MS. 
The BSS may attempt to internally re-route queued LLC frames to an MS that has been moved to a new cell. If this 
functionality is not supported, or if it is not possible to internally re-route LLC frames, the LLC frame shall be 
discarded. 

It is the responsibility of the higher layer protocols in the SGSN to cope with discarded LLC frames. 



6.2 Uplink UNITDATA procedure 



On the uplink, a UL-UNITDATA PDU shall contain information elements derived from the RLC/MAC function 
(except when GTTP is used in the Um interface, see 3GPP TS 44.018), meaningful to higher-layer protocols in an 
SGSN, and an LLC-PDU. There shall be only one LLC-PDU per UL-UNITDATA PDU. The LLC-PDU shall always 
be the last information element in the UL-UNITDATA PDU, and shall be aligned on a 32 bit boundary for efficient 
processing. 

The BSS shall provide the TLLI associated to the MS to the SGSN. 

The BSS shall provide a BVCI and an NSEI indicating the PTP functional entity (i.e. the cell) upon which the 
LLC-PDU was received. The SGSN shall obtain the BVCI, the NSEI, and in the case of an IP sub-network may obtain 
the LSP and the NS Change IP endpoint, from the underlying network service; the BVCI and the NSEI are not visible in 
the UL-UNITDATA PDU. 
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The BSS provides the SGSN with the QoS Profile used in the LLC-PDU transmission from the mobile station across 
the radio interface. 

QoS Profile. This reports the (peak) bit rate, the precedence used at radio access and the transmission mode used 
across the radio path. The type of the BSSGP SDU, layer 3 signalling or data, and the type of LLC frame, 
SACK, ACK, or not, are not meaningful on the uplink and shall be ignored. 

Packet Flow Identifier. This identifies the packet flow context that is obtained from the mobile. If the mobile 
station does not provide a PFI then the BSS shall use the pre-defined PFI to indicate best-effort QoS. 

In order to support location based services, the BSS shall include the cell identifier of the cell upon which the 
LLC-PDU was received. 

In the case where localised service area is supported, the BSS shall include the LSA identities of the cell upon which the 
LLC-SDU was received. The BSS may exclude LSA identities that are not included in the LSA INFORMATION 
element. 

In addition to constructing the UL-UNITDATA, the BSS supplies the LSP, the NSEI, the BVCI, and for an IP sub- 
network the NS Change IP endpoint, associated with the MS to the lower layer network service, enabling network 
service routeing to the peer entity. These parameters are not transmitted as part of the BSSGP across the Gb-interface. If 
the Gb-interface is supported using an IP sub-network, then the Resource Distribution function at the BSS may transmit 
a BSSGP UL-UNITDATA PDU with an LLC-PDU Length Indicator set to 0. The SGSN uses this UL-UNITDATA to 
change the IP endpoint at the BSS to which any future DL-UNITDATA for the TLLI (indicated in the 
UL-UNITDATA) is sent. 

Specific handling related tothe use of network sharing in a cell is described in sub-clause 6.6 for a mobile station non 
supporting network sharing. In the case of a mobile station supporting network sharing the BSS shall include the 
selected PLMN ID within the UL-UNIDATA PDU when a foreign TLLI or a random TLLI is included in the same UL- 
UNIDATA PDU, as described within sub-clause 10.2.2; both MS support and selected PLMN ID shall be derived by 
the BSS from information within the RLC data block as described within 3GPP TS 44.060 [22]. 

6.2.1 Abnormal conditions 

None specified. 



6.3 RA-CAPABILITY procedure 



The SGSN stores an MS's current radio access capability (which may be changed by higher layer mobility management 
procedures). An MS's current radio access capability, and the TLLI identifying the MS, are conveyed to a BSS in a 
RA-CAPABILITY PDU. The received MS's radio access capability, if valid, shall then replace any radio access 
capability previously associated with the MS. 

6.3.1 Abnormal conditions 

If the BSS receives an unknown Access Technology Type in the MS Radio Access Capability field, it shall ignore the 
fields associated with that Access Technology type. 

If the BSS receives unknown fields within a known Access Technology Type in the MS Radio Access Capability field, 
it shall ignore the unknown fields. 

6.4 Downlink MBMS-UNITDATA procedure 

On the downlink, a DL-MBMS-UNITDATA PDU shall contain information elements to be used by an LLC-PDU. 
There shall be only one LLC-PDU per DL-MBMS-UNITDATA PDU. The LLC-PDU shall always be the last 
information element in the DL-MBMS-UNITDATA PDU, and shall be aligned on a 32 bit boundary for efficient 
processing. 

An SGSN provides the BSSGP with a current TMGI, if available, and MBMS Session Identity, identifying the MBMS 
Service Context. 

The information made available to the radio interface includes: 
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PDU Lifetime. This defines the remaining time period that the PDU is considered as valid within the BSS. If the 
PDU is held for a period exceeding the "PDU Lifetime" time period, the PDU shall be locally discarded. The 
PDU Lifetime is set within the SGSN by the upper layers. 

A BSS may incorporate the PDU Lifetime into its radio resource scheduler. 

In addition to constructing the DL-MBMS-UNITDATA, the SGSN supplies the BVCI and the NSEI to the BSS. 

6.5 Uplink MBMS-UNITDATA procedure 

On the uplink, a UL-MBMS-UNITDATA PDU shall contain an LLC-PDU. There shall be only one LLC -PDU per 
UL-MBMS-UNITDATA PDU. The LLC-PDU shall always be the last information element in the UL-MBMS- 
UNITDATA PDU, and shall be aligned on a 32 bit boundary for efficient processing. 

The BSS shall provide the TMGI and, if present in the MBMS Service Context, the MBMS Session Identity to the 
SGSN in order to identify the MBMS session. 

The BSS shall provide a BVCI and an NSEI indicating the PTM functional entity upon which the LLC-PDU was 
received. The SGSN shall obtain the BVCI, the NSEI, and in the case of an IP sub-network may obtain the LSP and the 
NS Change IP endpoint, from the underlying network service; the BVCI and the NSEI are not visible in the UL- 
MBMS-UNITDATA PDU. 

In addition to constructing the UL-MBMS-UNITDATA, the BSS supplies the LSP, the NSEI, the BVCI, and for an IP 
sub-network the NS Change IP endpoint, associated with the MBMS session to the lower layer network service, 
enabling network service routeing to the peer entity. These parameters are not transmitted as part of the BSSGP across 
the Gb-interface. If the Gb-interface is supported using an IP sub-network, then the resource distribution function at the 
BSS may transmit a BSSGP UL-MBMS-UNITDATA PDU in order to change the IP endpoint at the BSS to which any 
future DL-MBMS-UNITDATA for the MBMS session (indicated with TMGI and, if available, MBMS Session Identity 
in the UL-MBMS-UNITDATA) shall be sent from the SGSN. 

NOTE: In this version of the specification, the procedure is used for resource distribution only meaning that the 
LLC PDU length indicator shall always be set to zero. 

6.6 Rerouting procedure in case of IVIOCN configuration for 
network sharing 

6.6.1 General 

This procedure shall be supported by a BSS if and only if it supports the MOCN configuration (see [43]). 

In the MOCN configuration the radio access part of the network is shared. There may be more than one Gb-Interface 
towards the PS domain of different CN operators from the BSS. 

Rerouting procedure is a mechanism used as part of the assignment of CN operator in shared networks with MOCN 
configuration when they perform initial attach/registration. In this case BSS may not know towards which SGSN to 
route the initial MS request message and the latter may be rerouted to another SGSN by BSS. 

More precisely, in case of MOCN configuration, the selection of SGSN in BSS is based on the NRI (valid or invalid) or 
by random selection. In case where the SGSN cannot be deduced from the NRI and a GPRS attach or routing area 
updating initial layer 3 message (defined in [11]) shall be transferred in UL-UNITDATA message towards a SGSN, 
BSS shall choose a SGSN and initiate a rerouting procedure. 

To trigger a rerouting procedure in MOCN configuration, the BSS adds the Redirect Attempt Flag IE to the UL- 
UNITDATA message, in order to indicate that the SGSN shall respond by including either Redirection Indication IE or 
Redirection Completed IE in DL-UNITDATA. 
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6.6.2 Reroute Indication 

If the SGSN cannot serve the request and reroute is possible (error causes are related to subscription options - defined in 
[11]), the reject Layer 3 Information LLC-PDU (e.g. GPRS attach Reject) and a Redirection Indication IE containing a 
Reroute Reject Cause shall be included in the DL-UNITDATA message for the downlink direction. 

When the IMSI is not included in the UL-UNITDATA message and CS/PS domain registration coordination is required 
(see [43]), the Initial LLC-PDU and a Redirection Indication IE containing the Reroute Reject Cause set to 'CS/PS 
domain registration coordination required' shall be included in the DL-UNITDATA message for the downlink direction. 
CS/PS domain registration coordination may not be performed for the operator" s own subscribers by the SGSN. 

In addition the DL-UNITDATA shall contain: 

- The Initial LLC-PDU received from the MS ; 

- The IMSI, if available; 

The Unconfirmed send state variable, if available. 

In MOCN configuration, if the BSS receives the Redirection Indication IE in the DL-UNITDATA message from a 
SGSN which is not the last attempted, it shall re-initiate the procedure towards another CN operator when possible (or 
possibly to the same CN in case when CS/PS domain registration coordination is required), with in the UL- 
UNITDATA message: 

- The Initial LLC-PDU as LLC-PDU; 
The Redirect Attempt Flag IE ; 

The IMSI, if received from one of previously attempted CN operators; 

The Unconfirmed send state variable, if received from previously attempted CN operator. 

Upon reception of the downlink Redirection Indication IE, the BSS shall store as part of the Rerouting Function the 
associated Reroute Reject Cause and LLC-PDU related to this SGSN. In case the Reroute Reject Cause is set to 
"CS/PS domain registration coordination required", then the BSS shall perform CS/PS domain registration coordination 
based on the received IMSI. In this case the Reroute Reject Cause value and the associated LLC-PDU shall not be 
stored. 

In case all attempted CN operators have replied with a Redirection Indication IE, the BSS shall select the most 
appropriate Layer 3 Information received from the attempted CN nodes based on the stored information as part of the 
Rerouting procedure and send it back to the MS (see [11). 



6.6.3 Reroute complete 



If the SGSN can serve the request, the Redirection Completed IE with outcome value set to "MS is accepted" or "MS is 
already registered" and Layer 3 Information LLC-PDU (e.g. GPRS Attach Accept) shall be included in the DL- 
UNITDATA message for the downlink direction. 

Upon reception of the downlink Redirection Completed IE, the BSS shall send back the included LLC-PDU to the MS 
and terminate the Rerouting procedure. 

6.6.4 Abnormal Conditions 

If the SGSN cannot serve the request and rerouting is not possible, the Redirection Completed IE with outcome value 
set to "MS is not accepted" and Layer 3 Information LLC-PDU (e.g.GPRS Attach Reject) shall be included in the DL- 
UNITDATA message for the downlink direction. 
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7 Signalling procedures between GMM SAPs 

7.1 Paging procedure 

When an SGSN initiates the paging procedure for GPRS services as defined in 3GPP TS 24.008, it shall send one or 
more PAGING-PS PDUs to the BSS. 

When instructed by an MSC/VLR to initiate a paging procedure for non-GPRS services as defined in 3GPP TS 24.008, 
an SGSN shall send one or more PAGING-CS PDUs to the BSS. 

These paging PDUs shall contain the information elements necessary for the BSS to initiate paging for an MS within a 
group of cells. 

The SGSN provides an indication of the cells within which the BSS shall page the MS. The levels of resolution within 
one BSS are: all cells within the BSS, all cells on the BSS within one location area, all cells on the BSS within one 
routing area, and one BVCI (i.e. cell). A routing area, a location area, or a BSS area is associated with one or more 
NSEIs. If the cells in which to page the MS are served by several NSEIs then one paging PDU must be sent to each of 
these NSEIs. 

A paging PDU shall be used to generate the corresponding radio interface paging request message(s) to be transmitted 
at the appropriate time. 

It should be noted that each paging PDU relates to only one MS and therefore a BSS may pack pages for different MSs 
into the relevant 3GPP TS 24.008 or 3GPP TS 44.060 radio interface paging request messages. 

In the case of paging for non-GPRS services, the SGSN shall provide the MS's IMSI and DRX Parameters. The SGSN 
shall also include the Global CN-Id information element in the paging PDU when this information element is received 
from the MSCA'LR. The Global CN-Id information element is received from the MSC/VLR if paging using only the 
IMSI parameter as identifier of the MS is performed via the SGSN when the MSC/VLR applies intra domain 
connection of RAN nodes to multiple CN nodes as described in 3GPP TS 23.236. The BSS shall then buffer this 
information element until receiving the paging response from the MS in order to route the paging response to the correct 
MSC/VLR. 

In the case of paging for GPRS services, the SGSN shall provide the MS's IMSI. If DRX Parameters are available, the 
SGSN shall also provide the DRX Parameters. 

NOTE: The IMSI and the DRX Parameters enable the BSS to derive the paging population number. Paging 
without DRX parameters may require a considerable extension of the paging duration. 

An SGSN may provide the BSSGP with MS specific information, enabling a BSS to execute the paging procedure in an 
MS specific manner. This includes: 

QoS Profile. The Precedence parameter is set by the upper layers (in the SGSN). The SGSN shall set the bit rate 
parameter to "best effort". The SGSN shall set the transmission mode to unacknowledged. The BSS shall ignore 
the received bit rate, the BSSGP SDU type, LLC type, and transmission mode parameters; 

PFI or an aggregate BSS QoS profile information which indicates if the page is for signalling, for SMS, for 
TOM8, for best-effort, or for a specific packet flow. The aggregate BSS QoS profile in this case is used for 
paging only and is not stored by the BSS. If both of the optional PFI and ABQP lEs are present, the ABQP takes 
precedence. 

If an SGSN provides a P-TMSI in a PAGING-PS PDU, then the BSS shall use the P-TMSI to address the MS. If the 
SGSN does not provide the P-TMSI in the PAGING-PS PDU, then the BSS shall use the IMSI to address the MS. 

If an SGSN provides a TLLI in a PAGING-CS PDU and a radio context identified by the TLLI exists within the BSS, 
then the paging request message shall be directly sent to the MS. If the SGSN does not provide the TLLI in the 
PAGING-CS PDU or if no radio context identified by the TLLI exists within the BSS, then the BSS shall use the TMSI, 
if provided in the PAGING-CS PDU, else the IMSI, to address the MS. 

The PAGING-CS PDU consists of the parameters described above for a PAGING-PS PDU (except the P-TMSI, PFI, 
ABQP and QoS profile parameters) and, optionally, some or all of the following parameters; TMSI, TLLI, Global CN- 
Id, Channel Needed and eMLPP -Priority. The Channel Needed and eMLPP-Priority information shall be handled 
transparently by the BSS. 



£75/ 



3GPP TS 48.01 8 version 1 1 .3.0 Release 1 1 46 ETSI TS 1 48 01 8 V1 1 .3.0 (201 3-07) 

7.2 Radio Access Capability Update procedure 

The BSS may request an MS's current Radio Access capability and/or its IMSI by sending to an SGSN a 
RA-CAP ABILITY-UPDATE PDU which includes the TLLI of the MS and a Tag. The allocation of the Tag is 
implementation specific. The BSS then starts timer T5. 

The SGSN shall respond by sending a RA-CAP ABILITY-UPDATE-ACK PDU which includes the TLLI of the MS, 
the Tag received in the corresponding RA-CAP ABILITY-UPDATE PDU, and an RA-Cap-UPD-Cause field; the IMSI 
of the MS is also included when known. The BSS shall stop timer T5. 

If the RA-Cap-UPD-Cause is set to "OK", then an MS Radio Access CapabiHty field and the IMSI shall be present. The 
received MS's radio access capability, if valid, shall then replace any radio access capability previously associated with 
the MS. If the RA-Cap-UPD-Cause is not set to "OK", then neither the MS Radio Access Capability nor the IMSI shall 
be present in the RA-CAP ABILITY-UPDATE-ACK PDU. 

7.2.1 Abnormal conditions 

If an SGSN receives a RA-CAP ABILITY-UPDATE PDU which includes an unknown TLLI, it shall answer with a 
RA-CAP ABILITY-UPDATE-ACK PDU which includes the RA-CAP-UPD-Cause set to the value "TLLI unknown". 

If an SGSN receives a RA-CAP ABILITY-UPDATE PDU which includes a known TLLI, but there are no Radio Access 
parameters or IMSI known to the SGSN for the associated MS, the SGSN shall reply to the request with a 
RA-CAP ABILITY-UPDATE-ACK PDU in which the RA-CAP-UPD-Cause is set to: "no RA capability or IMSI 
available". 

If a BSS receives a RA-CAP ABILITY-UPDATE-ACK PDU containing a Tag which is different from the last 
transmitted Tag by the BSS, it shall ignore the reception of this PDU. 

If a BSS sends a RA-CAP ABILITY-UPDATE PDU to an SGSN and the RA-CAP ABILITY-UPDATE-ACK is not 
returned within a period T5 with the same Tag value as provided in the request, the RA-CAP ABILITY-UPDATE 
procedure shall be repeated a maximum of RA-CAP ABILITY-UPDATE-RETRIES attempts. The Tag value shall be 
changed by the BSS at each new retry. 

7.3 Radio Status procedure 

A BSS and an MS radio interface communication status may change due to the following: 

1) the MS goes out of coverage and is lost; 

This condition is signalled by setting the Radio Cause value to "Radio contact lost with MS". 

2) the link quality is too bad to continue the communication; 

This condition is signalled by setting the Radio Cause value to "Radio link quality insufficient to continue 
communication" . 

3) the BSS has ordered the MS to perform a cell reselection. 

This condition is signalled by setting the Radio Cause value to "Cell reselection ordered". 

4) the BSS is preparing to order the MS to perform a cell-reselection to a new cell and internal re-routing of packets 
to the new cell is not possible. 

This condition is signalled by setting the Radio Cause value to "Cell reselection preparation". 

5) the BSS has detected that the packet cell change order has failed. 

This condition is signalled by setting the Radio Cause value to "Cell reselection failure". 

Conditions 1) and 2) indicate that attempts to communicate between an MS and an SGSN via this cell should be 
suspended or abandoned. An SGSN shall stop sending LLC-PDUs to the cell for the MS. The criteria for deciding 
whether condition 1) or 2) has occurred is not in the scope of the present document. 
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The conditions for resuming a suspended or abandoned communication between an MS and SGSN are defined in 
3GPP TS 24.008. 

Condition 3) indicates that the SGSN should wait for a cell update before resuming the transmission of LLC-PDUs to 
the BSS. 

Condition 4) indicates that the SGSN shall suspend downlink transmission of LLC-PDUs. This condition shall only be 
signalled if the Enhanced Radio Status feature has been negotiated. For this condition the SGSN shall wait for either: 

a) a cell update from the MS in a new Cell . In this case the SGSN should resume downlink transmission in the new 
Cell. 

b) or a new RADIO-STATUS PDU from the BSS with a different Radio Cause value. In this case the SGSN should 
follow the procedures specified for that Radio Cause value. 

Condition 5) indicates that the SGSN shall resume the transmission of LLC-PDUs to the BSS in case the downlink 
transmission has been suspended. This condition shall only be signalled if the Enhanced Radio Status feature has been 
negotiated.A BSS shall signal these exception conditions to an SGSN by sending a RADIO-STATUS PDU. It shall 
contain a reference to the MS, either TLLI or TMSI or IMSI, and an indication of the exception condition, i.e. the Radio 
Cause value. 

After receipt of a RADIO-STATUS PDU with cause value indicating Condition 1-4, the SGSN may try to locate the 
mobile station in case any downlink LLC PDU needs to be sent to the mobile station, as it can not expect to receive 
systematically an uplink LLC PDU from the mobile station or a RADIO-STATUS PDU with cause value indicating 
Condition 5 from the BSS to resume the downhnk transfer. To this avail, the SGSN should send a PAGING-PS PDU 
towards the mobile station. 



7.4 SUSPEND procedure 



If the MS signals to the BSS that it wishes its GPRS service to be suspended, the BSS shall send a SUSPEND PDU to 
the SGSN and start timer T3. Actions within the SGSN while an MS is suspended are not specified, but paging is 
typically stopped. The SUSPEND PDU contains: 

- theTLLIoftheMS;and 

the Routeing Area of the MS as received in the Layer 3 Um interface message GPRS Suspension Request (see 
3GPPTS 44.018). 

For each SUSPEND PDU received by an SGSN, a SUSPEND-ACK PDU shall be returned to the BSS. Upon reception 
of the SUSPEND-ACK PDU, the BSS shall stop T3. The SUSPEND-ACK PDU contains: 

- the TLLI of the MS as received in the SUSPEND PDU; 

- the Routeing Area of the MS as received in the SUSPEND PDU; and 

the Suspend Reference Number. 

The SGSN generates the Suspend Reference Number in a manner that it enables it to differentiate between different 
SUSPEND PDUs relating to the same MS. 

7.4.1 Abnormal conditions 

If a SUSPEND-ACK PDU is not received for a SUSPEND PDU within T3 seconds, then the SUSPEND PDU 
procedure shall be repeated a maximum of SUSPEND-RETRIES attempts. After SUSPEND-RETRIES attempts the 
procedure is stopped and the O&M system is informed. 

If a SUSPEND-ACK PDU is received for an MS that is already marked as suspended, then the SUSPEND-ACK PDU 
is ignored. 

If a SUSPEND PDU refers to an MS which is unknown in the SGSN, then a SUSPEND-NACK PDU is returned 
containing a cause value (Cause value: Unknown MS). The BSS shall stop the SUSPEND procedure. 

If the Suspend procedure is supported on the Gn interface, in case of an inter-SGSN suspend procedure the MS shall not 
be treated as unknown in the SGSN when the RA indicated in the SUSPEND PDU is not served by the SGSN. 
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7.5 RESUME procedure 

When the reason why a GPRS -attached MS was suspended disappears, i.e.: 

it leaves dedicated mode, disconnecting the MS from the MSC; or 

it is handed over to a cell that supports DTM; 

the BSS shall either a) instruct the MS to initiate the Routeing Area Update procedure, or b) signal to the SGSN that an 
MS's GPRS service shall be resumed. 

If the BSS executes a), then no frirther action is required. 

If the BSS executes b), then the BSS shall send a RESUME PDU containing the same Suspend Reference Number 
received in the SUSPEND-ACK PDU to the SGSN and start timer T4. The RESUME PDU contains: 

- theTLLIoftheMS; 

the Routeing Area of the MS; and 

the Suspend Reference Number. 

For each RESUME PDU received by an SGSN, a RESUME-ACK PDU shall be returned to the BSS. Upon reception of 
the RESUME-ACK PDU, the BSS shall stop T4. The RESUME-ACK PDU contains: 

- theTLLIoftheMS; and 

the Routeing Area of the MS. 

7.5.1 Abnormal conditions 

If a RESUME-ACK PDU is not received for a RESUME PDU within T4 seconds, then the RESUME PDU procedure 
shall be repeated a maximum of RESUME-RETRIES attempts. After RESUME-RETRIES attempts the procedure is 
stopped, the O&M system is informed and the MS shall be instructed to initiate the Routeing Area Update procedure. 

If a RESUME-ACK PDU is received for an MS that is not suspended, then the RESUME-ACK PDU is ignored. 

If a RESUME PDU refers to an MS which is unknown in the SGSN, then a RESUME-NACK PDU is returned 
containing a cause value (Cause value: Unknown MS). The BSS shall stop the RESUME procedure and the MS shall be 
instructed to initiate the Routeing Area Update procedure. 



8 Signalling procedures between NM SAPs 

8.1 FLUSH-LL (logical link) procedure 

When an SGSN detects a cell change of an MS from a cell update or a routing area update, the SGSN shall send a 
FLUSH-LL PDU to the old BVC to initiate the following procedures: 

at a cell change within one NSE (e.g. the BSS is a NSE) and within one routing area, LLC-PDU(s) for a given 
TLLI stored at an "old" BVCI (corresponding to the old cell) are either deleted or transferred to a "new" BVCI 
(corresponding to the new cell) with which the TLLI is currently associated; or 

at a cell change between two NSEs within one routing area, LLC PDU(s) for a given TLLI stored at an "old" 
BVCI (corresponding to the old cell) are either deleted or transferred to a "new" BVCI (corresponding to the 
new cell) with which the TLLI is currently associated. In that case, transferring of LLC PDU(s) can only be 
requested by the SGSN if the NSE underlying the "old" BVCI indicated support for the "Inter-NSE re-routing"; 

at a cell change within the same routing area, and within one NSE or between two NSEs, the on-going location 
procedure, if any, is either maintained in the BSS after the cell reselection or aborted by the BSS towards the 
SMLC; or 
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at a cell change between two routing areas, LLC-PDU(s) stored at the "old" BVCI for the TLLI are deleted. 
The SGSN provides the BSSGP with: 

- a MS's TLLI identifying the MS; 

- the "old" BVCI identifying the cell in which to find buffered LLC-PDU(s) for the MS; 

the "new" BVCI identifying the cell to which the MS is currently associated (only when within the same routing 
area); and 

- if the SGSN supports "Inter-NSE re-routing" or "LCS Procedures" and the old NSE supports the "Inter-NSE re- 
routing" or "LCS Procedures", the "new" NSEI identifying the cell to which the MS is currently associated (only 
when within the same routing area but between two NSEs). The NSEI associated to the "old" BVCI shall be 
assumed if the "new NSEI" field is not provided. 

If there is a BSS context for the MS in the "old" BVCI and there is a "new" BVCI in the FLUSH-LL PDU, the BSS 
shall interpret this as a request to transfer the BSS context to the new cell. The BSS shall assume that the ABQP 
that was negotiated for each PFC in the "old" BVCI is requested in the "new" BVCI by the SGSN. Also, the 
values of the Packet Flow Timer and the Service UTRAN CCO Information Elements should be kept for each 
transferred PFC. If, when receiving the BSS context at the "new" BVCI, the BSS has already obtained the 
information related to one or several PFC(s) from the SGSN by means of the Create BSS PFC procedure (see 
sub-clause 8a. 1), then the BSS shall disregard the information corresponding to this (these) PFC(s) within the 
BSS context transferred from the "old" BVCI. If a Create BSS PFC procedure is ongoing when receiving the 
BSS context at the "new" BVCI, the BSS shall either apply the received information or carry on with the 
currently used ABQP until the procedure completes. 

If a "new" BVCI is not provided, then the FLUSH-LL PDU shall be interpreted as an instruction to delete the queued 
LLC-PDU(s) at the old BVC, and also to delete the BSS context associated to the MS identified by the TLLI, if any 
exists in the "old" BVCI. 

Queued BSSGP signalling, e.g. pages, shall not be affected by this procedure. 

In response to a FLUSH-LL PDU the BSS shall send a FLUSH-LL-ACK PDU to the SGSN containing: 

- the TLLI received in the FLUSH-LL PDU; 

an indication of whether the LLC-PDU(s) were "transferred" or "deleted". In case the SDUs were "transferred" 
the BVCI (new) IE, and the NSEI (new) IE if present in the FLUSH-LL PDU, shall be included; 

the number of octets that have been transferred or deleted. 

NOTE: In situations where the BSS was unable to transfer the queued LLC-PDUs upon a transfer request from 
the SGSN, the BSS may indicate in the FLUSH-LL-ACK PDU a flush action set to "deleted" together 
with the number of octets actually deleted. 

On receipt of a FLUSH-LL-ACK PDU by the SGSN, indicating that the LLC-PDU(s) associated with the old BVC 
have been "deleted", the SGSN may choose to: 

immediately retransmit all unacknowledged LLC-PDU(s) (in acknowledged LLC operation) to the MS at the 
new BVC (i.e. new cell); or 

rely on LLC retransmission mechanism to transmit unacknowledged LLC-PDU(s). 

On receipt of a FLUSH-LL-ACK PDU by the SGSN, indicating that the LLC-PDU(s) associated with the old BVC 
have been "transferred", the SGSN shall not take any of the above actions. 

If the "new" BVCI could not accept the QoS characteristics of all PFCs of the BSS context, the BSS context shall still 
be transferred and the BSS shall then initiate in the "new" BVCI a Modify BSS PFC procedure for each PFC for which 
the requested ABQP could not be accepted. The BSS may resume the transfer of downlink LLC PDU(s) before the 
Modify BSS PFC procedure is completed. 

In order to avoid desequencing DL LLC PDU (in LLC acknowledged or unacknowledged operation) during the FLUSH 
procedure, upon sending a FLUSH-LL PDU to the BSS requesting the rerouting of DL LLC PDUs to a new cell, the 
SGSN should wait for the receipt of the FLUSH-LL-ACK PDU or rely on an internal guard timer, before starting to 
transmit subsequent DL LLC PDUs on the new BVCI. In the case the SGSN does not request the BSS to reroute DL 
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LLC PDUs to a new cell, it may immediately resume the transmission of subsequent DL LLC PDUs on the new BVCI, 
or start the Create BSS PFC procedure, without waiting for the receipt of the FLUSH-LL-ACK PDU. 

8.1.1 Abnormal Conditions 

If the BSS receives a FLUSH-LL PDU for an unknown BVCI or TLLI not associated with the given BVCI, then the 
FLUSH-LL PDU is discarded and no FLUSH-LL-ACK PDU is returned. 

If the SGSN does not receive a FLUSH-LL-ACK PDU in response to a FLUSH-LL PDU, no further action is taken. 

8.2 Flow Control procedure 

8.2.1 General model of operation 

From the perspective of the BSSGP, the flow control mechanism is based on the following model: 

there is a downlink buffer for each BVC, as identified by a BVCI, in a BSS; 

- the transfer of BSSGP UNITDATA PDUs for an MS from the SGSN is controlled by the BSS; and 

only downlink BSSGP UNITDATA PDU transfer to the BSS is managed via flow control procedures. Uplink 
flow control is not performed. 

8.2.2 Mode of operation 

The flow control mechanism manages the transfer of BSSGP UNITDATA PDUs sent by the SGSN on the Gb interface 
to the BSS. 

The BSS shall control the flow of BSSGP UNITDATA PDUs to its BVC buffers by indicating to the SGSN the 
maximum allowed throughput in total for each BVC. The BSS shall control the flow of BSSGP UNITDATA PDUs to 
the BVC buffer for an individual MS by indicating to the SGSN the maximum allowed throughput for a certain TLLI. If 
the PFC Flow Control feature is negotiated, the BSS may control the flow of BSSGP UNITDATA PDUs to the BVC 
buffer for a certain PFC of an individual MS by indicating to the SGSN the maximum allowed throughput for a certain 
PFI. 

If the Gigabit Interface feature has been negotiated, the granularity of the Flow Control related information elements 
such as the BVC Bucket Size IE, the BVC Bucket Leak Rate IE and the PFC flow control parameters IE shall be 
indicated through the Flow Control Granularity IE included in the same PDU (see sub-clauses 10.4.4, 10.4.6 and 
10.4.24). 

The BSS uses flow control to adjust the flow of BSSGP UNITDATA PDUs to a BVC buffer. The amount of buffered 
BSSGP UNITDATA PDUs in the BSS should be optimised to efficiently use the available radio resource. The volume 
of buffered BSSGP UNITDATA PDUs for a BVC or MS or PFC should be low. BSSGP UNITDATA PDUs queued 
within the BSS that are not transferred across the radio interface before the PDU Lifetime expires shall be locally 
deleted from the BSS. The local deletion of BSSGP UNITDATA PDUs in the BSS shall be signalled to the SGSN by 
the transmission of a LLC-DISCARDED PDU. 

For each FLOW-CONTROL PDU received by an SGSN, a confirmation shall always be sent across the Gb interface by 
the SGSN. The confirmation uses the Tag that was received in the FLOW-CONTROL PDU, which was set by the BSS 
to associate the response with the request. When receiving no confirmation to a FLOW-CONTROL PDU, the reasons 
that gave rise to the triggering of a flow control message may trigger another message, or, if the condition disappears, it 
may not. For the repetition of non-confirmed FLOW-CONTROL PDUs, the maximum repetition rate still applies in the 
BSS. 
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8.2.3 Flow Control of Traffic from an SGSN to BSS 



8.2.3.1 



Control of the downlink throughput by the SGSN 



The principle of the BSSGP flow control procedures is that the BSS sends to the SGSN flow control parameters which 
allow the SGSN to locally control its transmission output in the SGSN to BSS direction. The SGSN shall perform flow 
control on each BVC, on each MS and optionally on each PFC for an MS. The flow control is performed on each 
LLC-PDU first by the PFC flow control mechanism if applicable and if negotiated, then by the MS flow control 
mechanism and then by the BVC flow control mechanism. 

If the PFC Flow Control feature has been negotiated and the LLC-PDU corresponds to a PFC for which the SGSN has 
received some flow control parameters, then the SGSN has to check that the LLC-PDU is passed by the individual PFC 
flow control. If it is passed or if the PFC flow control has not been negotiated, or if it has been negotiated but no flow 
control parameter has been received for the PFC corresponding to the LLC-PDU, the SGSN applies the MS flow 
control. If passed, the SGSN finally applies the BVC flow control to the LLC-PDU. If an LLC-PDU is passed by all 
flow control mechanisms, the entire LLC-PDU is delivered to the Network Services for transmission to the BSS (see 
figure 8.1). 
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Figure 8.1 : BSSGP Flow control 

The flow control parameters sent by the BSS to the SGSN consist of the following information: 

the bucket size (Bmax) for a given BVC or MS or PFC in the downlink direction; and 

the bucket leak rate (R) for a given BVC or MS or PFC in the downlink direction; and 

the bucket full ratio for a given BVC or MS or PFC in the downlink direction, if the Current Bucket Level (CBL) 
feature is negotiated. 

NOTE: The information for a given PFC is only received if the PFC flow control feature is negotiated. 
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The SGSN shall perform flow control on an individual MS using SGSN determined values of Bmax and R unless it 
receives a FLOW-CONTROL-MS PDU from the BSS regarding that MS. The SGSN shall continue to perform flow 
control for a particular MS using the Bmax and R values received from the BSS for at least Th seconds after receiving a 
FLOW-CONTROL-MS PDU from the BSS regarding that MS. When timer Th has expired or when the MS changes 
cells, the SGSN may reinitialise the SGSN internal flow control variables for that MS and begin to use SGSN generated 
values for Bmax and R. 

The SGSN shall start performing flow control on a given PFC for an individual MS as soon as it receives the first 
FLOW-CONTROL-PFC PDU for that PFC and the feature has been negotiated; it shall stop applying PFC flow control 
for a given PFC of an individual MS as soon as it receives subsequently a FLOW -CONTROL-MS PDU for that MS or 
if more than Tf seconds have elapsed since the last FLOW-CONTROL-PFC PDU was received for that PFC. When the 
MS changes cells, the SGSN shall stop performing flow control per PFC, until it receives a FLOW-CONTROL-PFC 
PDU. 

In case the MS flow control parameters needs to be updated and the PFC flow control feature is negotiated and the PFC 
flow control parameters for that MS remains unchanged then the FLOW-CONTROL-PFC PDU is used by the BSS to 
update the MS flow control parameters. The "Number of PFCs" IE within the "PFC Flow Control parameters" IE shall 
be set to "0" in this case. 

The BSSGP flow control model is the algorithm shown in Figure 8.2. The model of the algorithm is that an LLC-PDU 
is passed by the algorithm as long as the bucket counter (B) plus the length of the LLC-PDU does not exceed the bucket 
size Bmax. When the LLC-PDU is passed, the LLC-PDU length is added to B. Any PDU not transmitted is delayed 
until B plus the LLC-PDU length is less than Bmax. 



8.2.3.2 



Flow Control Conformance Definition 



A BSSGP flow control algorithm shall be implemented in the SGSN. The BSSGP flow control conformance algorithm 
is defined in figure 8.2. 

The conformance definition is used to decide which LLC-PDUs are conforming to the flow to the PFC of an MS, to an 
MS or in a BSSGP virtual connection (BVC) over the Gb interface. The conformance definition should not be 
interpreted as the required implementation algorithm, as the SGSN manufacturer may use any algorithm as long as the 
operation of the BSSGP flow control does not violate the objectives of compliant BVCs or MSs or PFC. That is, the 
SGSN shall never transmit more data than can be accommodated within the BSS buffer for a BVC or individual MS or 
for a given PFC of an MS. 



Arrival of LLC PDU p with 
lengtln L(p) at time Tc 




Delay LLC PDU 



Pass LLC PDU 



Figure 8.2: Conformance Definition Algorithm for BSSGP Flow Control 
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The variables used by the algorithm are: 

Bmax Bucket Size. Set by the ESS for each cell and each mobile station and optionally for each PFC of an MS. 
Bmax shall be large enough to accommodate at least one LLC-PDU; 

R leak rate of the bucket; 

B bucket counter; 

B* predicted value of the bucket counter; 

L(p) length of LLC-PDU p; 

Tp the time that the last LLC-PDU p was transferred; and 

Tc arrival time of LLC-PDU p. 

The initial conditions of these variables in the SGSN are: 

- Bmax = for BVCs or MSs. For BVCs, this value is valid until Bmax is received in the FLOW-CONTROL- 
BVC. For MSs, this value is valid until Bmax_default_ MS is received in the FLOW-CONTROL-BVC PDU. 
Thereafter, sub-clause 8.2.3.6, shall apply; 

- Bmax = for PFCs until a FLOW-CONTROL-BVC PDU is received for the cell in which the PFC is running. 
Thereafter, Bmax for a PFC shall not be greater than Bmax of the corresponding MS until PFC flow control 
applies for the PFC. As long as PFC flow control applies, Bmax shall then not be greater than the value of Bmax 
provided in the latest valid FLOW-CONTROL-PFC PDU ; 

- R = for BVC or MSs. For a BVC, this value is valid until a FLOW-CONTROL-BVC PDU is received. For an 
MS, this value is valid until a FLOW-CONTROL-BVC PDU is received. Thereafter, sub-clause 8.2.3.6 shall 
apply; 

- R = for PFCs until a FLOW-CONTROL-BVC PDU is received for the cell in which the PFC is running. 
Thereafter, R for a PFC shall not be greater than R of the corresponding MS until PFC flow control applies for 
the PFC. As long as PFC flow control applies, R shall then not be greater than the value of R provided in the 
latest valid FLOW-CONTROL-PFC PDU ; 

B = (the bucket is empty); and Tp = the current time for the first LLC-PDU. 

The SGSN shall not transmit a LLC-PDU on a BVC until a FLOW-CONTROL-BVC PDU is received from the BSS for 
that BVC. 

When a LLC-PDU p arrives at current time Tc, the variable B* is set to the predicted bucket size if the LLC-PDU were 
to be transferred to the BSS. This is given by the previous bucket size plus the new LLC-PDU size, B* = B H- L(p), less 
the amount that the bucket will have leaked away since the last compliant LLC-PDU, R x (Tc - Tp). If this is less than 
L(p) then the LLC-PDU is compliant and the bucket size B is reset to L(p) and the LLC-PDU is passed. When a 
compliant LLC-PDU is passed the last LLC-PDU transfer time is set to the current time, Tp = Tc. 

If the bucket has not completely leaked away then the bucket has to be checked to see if the limit Bmax is going to be 
exceeded, B* > Bmax. If the limit is exceeded then the LLC-PDU is non compliant and is delayed for some time period, 
and no updates are done on the variables. If the bucket limit Bmax is not exceeded then the LLC-PDU is compliant and 
the bucket counter (B) is set equal to the value of B*. When a conforming LLC-PDU is passed then the last LLC-PDU 
transfer time is set to the current time, Tp = Tc. 

On receipt of a FLUSH-LL-ACK PDU by the SGSN, indicating that the LLC-PDU(s) associated with the old BVC 
have been "deleted", the SGSN should update the value of the bucket counter (B) for the MS and for the old BVC, 
B = max (B - N, 0). N is provided by FLUSH-LL-ACK PDU, indicating the number of octets deleted by the BSS. 

On receipt of a FLUSH-LL-ACK PDU by the SGSN, indicating that the LLC-PDU(s) associated with the old BVC 
have been "transferred" within the NSE, the SGSN should update the value of the bucket counter (B) for the old BVC, 
B = max (B - N, 0). The value of B for the new BVC should also be updated, B = min (B + N, Bmax). N is provided by 
FLUSH-LL-ACK PDU, indicating the number of octets transferred by the BSS. 
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On receipt of a LLC-DISCARDED PDU by the SGSN, indicating that the LLC-PDU(s) associated with the MS or the 
PFC of an MS have been locally deleted by the BSS, the SGSN should update the value of the bucket counter (B) for 
the MS or the PFC and for the BVC, B = max (B - N, 0). N is provided by LLC-DISCARDED PDU, indicating the 
number of octets deleted by the BSS. 

The BSS may update the values of Bmax and R within the SGSN at any time by transmitting a new Flow Control PDU 
containing the new Bmax and R values. The variables B, B*, Tp and Tc are local to the SGSN and are not affected by 
the reception of a Flow-Control-B VC or Flow Control-MS PDU. 

If the Current Bucket Level (CBL) feature is negotiated, the SGSN shall update the variable B based upon the 
Bucket_Full_Ratio information element received in the Flow Control PDU. During the time period when SGSN does 
not receive a Flow Control PDU, it shall continue computing the bucket counter (B) as defined above. 

8.2.3.3 Response time within the SGSN to flow control messages 

Upon reception of flow control requests from a BSS, the SGSN shall modify its downlink transmission as instructed 
within 100 ms. 

8.2.3.4 Frequency of sending BVC or MS or PFC Flow Control PDUs 

The rate at which the BSS is allowed to send flow control PDUs for a given BVC or MS or PFC is limited and defined 
by the following rule: the BSS may send a new Flow Control PDU every C seconds, where C is a value which is 
pre-defined and common to the BSS and SGSN. 

If the BSS detects a missing FLOW-CONTROL-ACK PDU from the SGSN and the condition which causes the sending 
of a FLOW-CONTROL PDU still remains, the FLOW-CONTROL PDU may be retransmitted immediately. In this case 
the BSS may violate the repetition rate defined by the C value. 

After a BVC reset procedure, the BSS may send a BVC-BLOCK PDU. Otherwise, the BSS shall send a BVC-FLOW- 
CONTROL PDU. When the blocked BVC is unblocked, a BVC-FLOW-CONTROL PDU shall be sent. 

8.2.3.5 FLOW-CONTROL PDUs 

Based on the criteria for flow control, a BSS shall send to an SGSN a FLOW-CONTROL PDU containing a list of lEs. 
For BVC Flow Control, the following information is sent: 

the maximum bucket size (Bmax) for the BVC on the Gb Interface; 

the leak rate parameter (R) to be applied to the bucket; 

the bucket full ratio to resynchronize the bucket counter for the BVC, if the Current Bucket Level (CBL) feature 
is negotiated; 

- the default MS bucket size (Bmax_default_MS); 

- the default MS leak rate (R_default_MS); and 

the optional measurement of the delay for PDU delivery inside that BVC. 
For MS Flow Control, the following information is sent: 

- the TLLI identifying the MS ; 

the maximum bucket size (Bmax) for this MS on the Gb interface; 

- the leak rate parameter (R) to be applied to the bucket; and 

the bucket full ratio to resynchronize the bucket counter for the MS, if the Current Bucket Level (CBL) feature is 
negotiated. 

For PFC Flow Control, the following information is sent: 

- the TLLI identifying the MS ; 
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the maximum bucket size (Bmax) for this MS on the Gb interface (optional); 

- the leak rate parameter (R) to be applied to the bucket (optional); 

the bucket full ratio to resynchronize the bucket counter for the MS, if the Current Bucket Level (CBL) feature is 
negotiated (optional); 

the number of PFCs for which flow control parameters are included; 

for each PFC: 

- the PFI identifying the PFC for that MS; 

the maximum bucket size (Bmax) for this PFC on the Gb interface; 

the leak rate parameter (R) to be applied to the bucket; 

the bucket full ratio to resynchronize the bucket counter for the PFC, if the Current Bucket Level (CBL) 
feature is negotiated. 

NOTE: The supply of the MS flow control parameters inside the FLOW-CONTROL-PFC PDU allows the SGSN 
utilising the most up-to-date parameters both for PFC and MS flow control. Also, because the receipt of a 
FLOW -CONTROL-MS PDU notifies the end of PFC flow control for a given MS, if the MS flow control 
parameters have changed since the last update, then it is necessary to provide the MS flow control 
parameters inside the FLOW-CONTROL-PFC PDU. 

8.2.3.6 Condition of Bmax for MS after Initial Flow-Control-BVC 

The SGSN may use the following (informative) equation to generate an initial bucket size, Bmax, for an MS. 

Bmax (bits) = min (R_default_MS for 1 s, 72 000, max MS throughput for 1 s, (max MS throughput for 
1 s H- current throughput of all other MSs in the cell for Is)/ number of MSs in the cell) 

where, the number of MSs in the cell includes the MS being added. 

Under no circumstance shall the SGSN use a value of Bmax greater than Bmax_default_MS for an MS unless it 
receives a FLOW-CONTROL-MS PDU from the BSS for that MS. 

The SGSN shall not use a leak rate (R) for an MS greater than R_default_MS unless it receives a FLOW-CONTROL- 
MS PDU from the BSS for that MS. 

8.2.4 Flow Control of Uplink Traffic from a BSS to an SGSN 

No flow control procedures are defined between the BSS and the SGSN in uplink direction. 

8.3 BVC blocking and unblocking procedure 
8.3.1 PTP BVC 

The following statement applies only for PTP BVC. 

The BVC blocking and unblocking procedures are initiated by the BSS to remove from use, or bring in to use, a BVC. 

A BSS may block one BVC because of: 

operation and Maintenance intervention for a cell; 

equipment failure at the BSS; 

cell equipment failure at the BSS; or 

other causes not regarded in phase 1 of the implementation of GPRS (Cause Value: "reserved for future use"). 
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When a BSS wishes to block a BVC, the BSS shall mark that BVC as blocked, thereafter discarding any traffic sent to 
the BVC in the uplink direction. The cell associated with the BVC should not accept data in the downlink direction. The 
BSS shall send a BVC-BLOCK PDU to the SGSN and start timer Tl. The BVC-BLOCK PDU contains: 

- the B VCI of the BVC to be blocked; and 

a Cause element indicating the reason for blocking (typical cause values: O&M intervention, Equipment failure). 

On receipt of a BVC-BLOCK PDU, the SGSN shall mark the indicated BVC as blocked and stop transmitting traffic 
addressed to this BVC. The SGSN shall then acknowledge the blocking of the BVC by sending a BVC-BLOCK- ACK 
PDU to the BSS. 

The BVC-BLOCK- ACK PDU contains the BVCI received in the BVC-BLOCK PDU. 

On receipt of the BVC-BLOCK- ACK PDU the BSS shall stop timer TL 

The BVC shall be seen as blocked by an SGSN until a BVC-UNBLOCK PDU is received indicating that the BVC's 
status has changed. 

During the BVC blocking procedure, traffic in transit to or from a cell is in an indetermined state and may be lost. 
When unblocking a BVC both the BSS and SGSN shall be in an operational state, i.e. the underlying network service 
and the BVC shall be available for use. 

If a BSS wishes to unblock a blocked BVC it shall send a BVC-UNBLOCK PDU, and start timer TL 

The BVC-UNBLOCK PDU contains: 

- the BVCI of the BVC to be unblocked. 

If a BVC-UNBLOCK PDU is received by an SGSN for a blocked BVC, the BVC shall be marked as unblocked and a 
BVC-UNBLOCK-ACK PDU shall be returned to the BSS, containing the BVCI received in the BVC-UNBLOCK 
PDU. 

The BSS shall stop timer Tl on receipt of the BVC-UNBLOCK-ACK PDU and mark the BVC as unblocked. 



8.3.2 Signalling BVC 



The blocking and unblocking procedure is not applicable for the signalling BVC. The signalling BVC shall never be 
blocked. 

8.3.3 Abnormal Conditions 

The following statements apply only for a signalling BVC. 

If a BVC-BLOCK PDU is received by an SGSN for the signalling BVC, the PDU is ignored. 

If a BVC-BLOCK- ACK PDU is received by a BSS for the signalhng BVC, the PDU is ignored. 

If BVC-UNBLOCK PDU is received by an SGSN for the signalling BVC, the PDU is ignored. 

If BVC-UNBLOCK-ACK PDU is received by an BSS for the signalling BVC, the PDU is ignored. 

The following statements apply only for PTP BVC. 

If a BVC-BLOCK-ACK PDU is not received for a BVC-BLOCK PDU within Tl seconds, then the BVC-BLOCK PDU 
procedure shall be repeated a maximum of BVC-B LOCK-RETRIES attempts. After BVC-BLOCK-RETRIES attempts 
the BVC remains blocked, the procedure is stopped and the O&M system is informed. 

If a BVC-UNBLOCK-ACK PDU is not received for a BVC-UNBLOCK PDU within Tl seconds, then the BVC- 
UNBLOCK PDU procedure shall be repeated a maximum of BVC-UNBLOCK-RETRIES attempts. After BVC- 
UNBLOCK-RETRIES attempts the status of the BVC remains blocked, the procedure is stopped and the O&M system 
is informed. 

If traffic is received on a BVC that is marked at a BSS or at an SGSN as blocked, and no BVC -Unblocking procedure is 
pending, the received PDU shall not be accepted and a STATUS PDU (Cause value: BVC blocked) shall be sent to the 
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peer entity on the signalling BVC. The STATUS PDU shall indicate the BVCI of the BVC upon which the error was 
detected. 

If a B VC-BLOCK PDU is received by an SGSN for a blocked BVC, a B VC-BLOCK-ACK PDU shall be returned. 

If a B VC-UNBLOCK PDU is received by an SGSN for an unblocked BVC, a B VC-UNBLOCK-ACK PDU shall be 
returned. 

If an unexpected BVC-BLOCK-ACK PDU is received by a BSS, and it is related to a BVC that is locally blocked, the 
B VC-BLOCK-ACK PDU is discarded. If the BVC-BLOCK-ACK PDU is related to a BVC that is not locally blocked, 
then a BVC unblock procedure shall be performed. 

If an unexpected BVC -UNBLOCK- ACK PDU is received by a BSS and it is related to a BVC that is locally not 
blocked, the B VC-UNBLOCK-ACK PDU is discarded. If the BVC-UNBLOCK-ACK PDU is related to a BVC that is 
locally blocked, then a BVC block procedure shall be performed. 



8.4 BVC-RESET procedure 



The purpose of the BVC-RESET procedure is to synchronise the initialisation of GPRS BVC related contexts at a BSS 
and SGSN. This enables the BSS and SGSN to begin communication in known states. A BVC-RESET procedure is 
performed because of recovery procedures related to: 

a system failure in the SGSN or BSS that affects GPRS BVC functionality (e.g. processor recovery); 

an underlying network service system failure; or 

a change in the transmission capability of the underlying network service, where the "change" is from zero kbps 
to greater-than-zero kbps; 

a change in mapping between the BVCI and cell identifier. 

The BSS may also send BVC-RESET as a means to create the initial mapping between BVCIs and cell identifications. 

After any of the possible events stated above, the status of the affected BVCs may be inconsistent at the SGSN and the 
BSS. After performing the BVC Reset procedure all affected BVCs are assumed to be unblocked at the SGSN. The 
reset procedure forces a consistent state upon SGSN and BSS by requiring that after the completion of the B VC-Reset 
procedure the BSS initiates the block procedure for all affected BVCs that are marked as blocked at the BSS. 

Before a BSS (or SGSN) sends a BVC-RESET PDU, the operational status of the associated network service shall be 
obtained by the BSS (or SGSN). 

If the associated network service is operational, the BSS (or SGSN) shall send a BVC-RESET PDU to its peer entity 
and start timer T2. The BSS (or SGSN) may receive BVC related signalling and UNITDATA PDUs before the 
procedure is acknowledged, but shall not transmit PDUs. 

If the associated network service is not operational, the BVC-RESET procedure is postponed until internal periodic 
status checks indicate that it is operational. 

The BVC-RESET PDU contains: 

- the BVCI of the reset BVC; 

a cause element indicating the reason for reset; 

the cell identifier, when the reset is for a PTP BVC and BSS is initiator of the reset; 

feature bitmap, when the reset is for a signalling BVC. 
After the SGSN (or BSS) has initialised all affected GPRS related contexts, a BVC-RESET-ACK PDU is returned. 
The BVC-RESET-ACK PDU contains: 

- the BVCI of the reset BVC; 

the cell identifier, when the reset is for a PTP BVC and SGSN is initiator of the reset. 
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Upon reception by a BSS (or SGSN) of the BVC-RESET-ACK PDU the timer T2 is stopped. 



8.4.1 Signalling BVC 



After any failure affecting the NSE, the party (BSS or SGSN) where the failure resided shall reset the signalling BVC. 
After sending or receiving a BVC-RESET PDU for the signalling BVC, the BSS shall stop all traffic and initiate the 
BVC-RESET procedure for all BVCs corresponding to FTP functional entities of the underlying network service entity. 
The BSS must complete the BVC-RESET procedure for signalling BVC before starting FTP BVC-RESET procedures. 

The Feature bitmap is sent to identify the optional features that can be supported by the network service entity. After 
completion of the signalling BVC-RESET procedure both entities shall locally determine the common set of optional 
features supported by both NSEs. This is done by performing the bit AND operation of the received Feature bitmap 
with its own Feature bitmap. 

If the Feature bitmap IE is missing in a signalling BVC-RESET or BVC-RESET-ACK PDU or if the result of the AND 
operation is '0' then no optional features are activated. 

After sending or receiving a BVC-RESET PDU for the signalling BVC, the SGSN shall stop all traffic in the PTP 
BVCs of the corresponding NSE. 

8.4.2 PTP BVC 

After any failure affecting only part of the BVC functionality not including the signalling BVC the party where the 
failure resided shall reset only the affected BVCs. 

If the BSS was the initiator of the BVC-RESET procedure, the BSS may initiate the blocking procedure upon receipt of 
a BVC-RESET-ACK PDU. If the SGSN was the initiator of the BVC-RESET procedure while the affected BVC is 
marked as blocked at the BSS side, the BSS shall initiate the BVC-Blocking procedure after having returned the 
BVC-RESET-ACK PDU to the SGSN. 

Upon reception of a BVC-RESET PDU, the SGSN (or BSS) shall discard UNITDATA PDUs addressed to the reset 
BVC. 

After reset of a PTP BVC, UNITDATA PDUs addressed to the BVC may then be received and transmitted, unless it is 
blocked. 

8.4.3 Abnormal Conditions 

The following statements are valid for both signalling and PTP BVC. 

If a BSS (or SGSN) sends a BVC-RESET PDU to an SGSN (or BSS) and the BVC-RESET-ACK PDU is not returned 
within a period T2, the BVC-RESET procedure shall be repeated a maximum of BVC -RESET-RETRIES attempts. 
After BVC-RESET-RETRIES attempts the procedure is stopped and the O&M system is informed. In case of PTP 
BVC, the status of all affected BVCs at the BSS (or SGSN) shall be blocked as a consequence. 

If the BSS receives a BVC-RESET PDU for a B VCI which is unknown in the BSS, then the BSS shall return a 
STATUS PDU towards the SGSN including the BVCI and the cause value 'BVCI unknown'. 

If the BSS (or SGSN) has sent a BVC-RESET PDU for a BVCI to the SGSN (or BSS) and is awaiting a BVC-RESET- 
ACK PDU in response, but instead receives a BVC-RESET PDU indicating the same BVCI, then this shall be 
interpreted as a BVC-RESET ACK PDU and the T2 timer shall be stopped. 

The BVC_RESET for signalling BVC overrides all pending procedures for PTP BVC, i.e. other pending procedures are 
stopped and corresponding running timers are stopped. 

If the BSS (or SGSN) receives an unexpected BVC-RESET ACK PDU, this shall be ignored. 

If the BSS has sent a BVC-UNBLOCK PDU and receives a BVC-RESET PDU before the BVC-UNBLOCK-ACK 
PDU has been received from the SGSN, then the BSS shall consider the corresponding BVC marked as unblocked. 
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8.5 Trace procedure 



The purpose of the trace invocation procedure is to inform the receiving entity that it should begin producing a trace 
record on an MS. The trace is invoked by an SGSN by sending an SGSN-INVOKE-TRACE PDU to the peer entity. 
The SGSN-INVOKE-TRACE PDU is not acknowledged. 

The events and parameters to be recorded are indicated in the "Trace type" information element are defined in 
3GPP TS 32.008. 

The remaining elements, when received, are to be passed transparently to the OMC receiving the trace record. 

The element "OMCId", if present, indicates the OMC to which the record is destined. 

The PDU includes a trace reference which is allocated by the entity which triggered the trace. 

The element "Triggerld", if present, indicates the entity which triggered the trace. 

The Trace Reference and Triggerld lEs are used to tag the trace record to allow simpler construction of the total record 
by the entity which combines trace records. 



8.6 Overload Control procedure 



8.6.1 General 

This procedure is defined to control the traffic to the SGSN from BSC when the SGSN is in an overload situation. 

The philosophy used at BSS side is: 

If T15 is not running and an OVERLOAD PDU including the Priority Class Indicator IE is received, then traffic 
for the indicated priority class should be reduced by one step. At the same time, timers T15 and T16 should be 
started. 

- During T15, all received OVERLOAD PDU should be ignored. 

If T16 expires, the traffic should be increased by one step and T16 should be re-started unless full load has been 
resumed. 

The number of steps and the method of reducing/increasing the load are considered to be an implementation 
specific function. 



8.6.2 Overload Operation 



The SGSN could indicate to the BSS that it is in a congested state by sending an OVERLOAD PDU and request the 
BSS to reduce the traffic for the category of MSs indicated in the Priority Class Indicator IE. 

The BSS receiving the OVERLOAD PDU shall assume the SGSN sending the PDU as being in an overloaded state and 
reduce the traffic to the SGSN using the algorithm described in sub-clause 8.6.1. 

The amount of traffic could be reduced by using the Access Control Class in the system information message defined in 
3GPP TS 44.018. However it is implemention specific regarding how the BSS reduces the traffic in response to 
receiving an OVERLOAD PDU. 



£75/ 



3G PP TS 48.01 8 version 1 1 .3.0 Release 1 1 60 ETSI TS 1 48 01 8 V1 1 .3.0 (201 3-07) 

8a Signalling procedures between PFM SAPs 

8a. 1 Create BSS RFC procedure 
8a. 1.0 General 

If the BSS receives a request to transfer an uplink or downlink LLC PDU for which it currently does not have a BSS 
packet flow context and the PFI does not indicate best-effort or SMS or TOMS or signalling then the BSS should send a 
DOWNLOAD-BSS-PFC PDU to the SGSN and start timer T6. In the uplink case the TLLl, optional Radio Priority, and 
optional Packet Flow ID are received from the MS as defined in 3GPP TS 44.060. Until the BSS receives the BSS PFC 
the BSS shall handle uplink and downlink transfers according to a best-effort default aggregate BSS QoS profile. For 
uplink transfers the best-effort default profile is specific to the radio priority level. 

If the BSS receives a request to transfer an uplink or downlink LLC PDU associated to a PFI indicating best-effort or 
SMS or TOMS or signalling then the BSS may handle the corresponding transfer according to an operator-defined 
aggregate BSS QoS profile. Indeed the latter cannot be negotiated with the SGSN for those flows. It is also up to the 
implementation what Allocation/Retention Priority is granted to those flows. 

If the BSS does not receive a PFI from the MS, e.g. from a R97 or R9S MS, the BSS shall not send a DOWNLOAD- 
BSS-PFC PDU to the SGSN. In this case the QoS Profile IE is utilized instead. 

Following a DOWNLOAD-BSS-PFC PDU if there is not an ongoing Delete PFC procedure for that corresponding PFI, 
the SGSN shall send a CREATE-BSS-PFC PDU to the BSS with a requested Aggregate BSS QoS Profile and start 
timer T7. On receipt of CREATE-BSS-PFC PDU the BSS stops timer T6 and responds with a CREATE-BSS-PFC- 
ACK PDU containing the negotiated Aggregate BSS QoS Profile. The BSS may restrict the requested ABQP given its 
capabilities and the current load. The SGSN may include the Service UTRAN CCO (Cell Change Order) information 
element in the PDU (relevant if the network initiated cell change order to UTRAN, network initiated cell change order 
to E-UTRAN, PS handover to UTRAN or PS Handover to E-UTRAN procedures are used). If this information element 
is received in multiple PDUs (either DL-UNITDATA PDU(s), CREATE-BSS-PFC PDU(s) or PS-HANDOVER- 
REQUEST PDU(s)), the information element contained in last received PDU shall take precedence. If there is an 
ongoing Delete PFC procedure the SGSN shall not send a CREATE-BSS-PFC-PDU (see subclause Sa.3). 

The SGSN may also initiate the Create BSS PFC procedure. It is not required that the SGSN receive a 
DOWNLOAD-BSS-PFC PDU before sending a CREATE-BSS-PFC request. 

The CREATE-BSS-PFC PDU may trigger a call admission control algorithm in the BSS to check whether the requested 
ABQP can be served. If there is valid MS Radio Access Capability IE known by the SGSN for the associated MS, the 
SGSN shall include it in the CREATE-BSS-PFC PDU. If the MS Radio Access Capability IE are not present in the 
request, then the Radio Access Capability Update procedure may be called. 

The BSS may return a CREATE-BSS-PFC -NACK with a cause if it is unable to create or modify the PFC. On receipt 
of a CREATE-BSS-PFC-ACK PDU which does not convey the cause 'PFC queuing' (cf. sub-clause Sa.l.Oa) or of a 
CREATE-BSS-PFC-NACK PDU the SGSN shall stop timer T7. 

The Packet Flow Timer (PET) is provided to the BSS by the SGSN. It is defined as the maximum time the BSS may 
hold the PFC during periods of inactivity for a PFC. The timer is started upon the receipt of a CREATE-BSS-PFC PDU 
and restarted after the transmission of an uplink PDU for that PFC. The timer is also restarted upon the transfer of the 
corresponding PFC from an old to a new cell. 

If a CREATE-BSS-PFC PDU is received for an MS which has a BSS PFC in the BSS, then this shall be interpreted by 
the BSS as a request to: 

create a new PFC if the PFI included in the PDU is not known in the BSS, 

modify an existing PFC if the PFI included in the PDU is already known in the BSS. 

The SGSN may inform the BSS about the contents of SPID in the CREATE-BSS-PFC PDU. In this case the SPID is 
stored in the BSS. 



£75/ 



3GPP TS 48.01 8 version 1 1 .3.0 Release 1 1 61 ETSI TS 1 48 01 8 V1 1 .3.0 (201 3-07) 

8a. 1.0a Allocation/Retention Priority handling 

The SGSN may include the Allocation/Retention Priority information element in the CREATE-BSS-PFC- PDU. If this 
information element is received and the BSS supports ARP handling, the BSS shall establish or modify the resources 
according to the values of the Allocation/Retention Priority IE (priority level, pre-emption indicators, queuing) and the 
resource situation as follows: 

The BSS shall consider the priority level of the requested PFC, when deciding on the resource allocation. 

If the requested PFC is allowed for queuing and the resource situation so requires, the BSS may place the PFC in 
the establishment queue. 

The priority levels and the pre-emption indicators may (singularly or in combination) be used to determine 
whether the PFC assignment has to be performed unconditionally and immediately. If the requested PFC is 
marked as "may trigger pre-emption" and the resource situation so requires, the BSS may trigger the pre-emption 
procedure which may then cause the forced release of a lower priority PFC which is marked as "pre-emptable". 
Whilst the process and the extent of the pre-emption procedure is operator dependent, the pre-emption indicators, 
if given in the CREATE-BSS-PFC PDU, shall be treated as follows: 

1 . The values of the last received Pre-emption Vulnerability IE and Priority Level IE shall prevail. 

2. If the Pre-emption Capability IE is set to "may trigger pre-emption", then this allocation request may trigger 
the pre-emption procedure. 

3. If the Pre-emption Capability IE is set to "shall not trigger pre-emption", then this allocation request shall not 
trigger the pre-emption procedure. 

4. If the Pre-emption Vulnerability IE is set to "pre-emptable", then this connection shall be included in the pre- 
emption process. 

5. If the Pre-emption Vulnerability IE is set to "not pre-emptable", then this connection shall not be included in 
the pre-emption process. 

6. If the Priority Level IE is set to "no priority" the given values for the Pre-emption Capability IE and Pre- 
emption Vulnerability IE shall not be considered. Instead the values "shall not trigger pre-emption" and "not 
pre-emptable" shall prevail. 

If the Allocation/Retention Priority IE is not given in the CREATE-BSS-PFC -PDU, the allocation request shall 
not trigger the pre-emption process and the connection may be pre-empted and considered to have the value 
"lowest" as priority level. Moreover, queuing shall not be allowed. 

The BSS pre-emption process shall keep the following rules: 

1. The BSS shall only pre-empt PFCs with lower priority, in ascending order of priority. 

2. The pre-emption may be done for PFCs belonging to the same MS or to other MSs. 

If the BSS is unable to create the PFC immediately and the ARP IE was present in the CREATE-BSS-PFC PDU 
indicating that queuing is allowed for the PFC, the BSS may put the PFC creation request or modification in a queue. In 
that case, it shall send a CREATE-BSS-PFC-ACK PDU including the cause 'PFC queuing' to the SGSN and start the 
timer TIO. This timer specifies the maximum time for queuing of the request of establishment or modification; its value 
is provided by the SGSN in the CREATE-BSS-PFC PDU. Several PFCs for a given MS may be queued in parallel. 
While a PFC is queued, the BSS shall handle the corresponding uplink or downlink transfers according to a best-effort 
default aggregate BSS QoS profile. 

For each PFC that is queued the following outcomes shall be possible: 

successfully established or modified; 

failed to establish or modify; 

failed due to expiry of the timer TIO. 

When the SGSN receives the response that the requested PFC is queued, the SGSN shall expect the BSS to provide the 
outcome of the queuing function for the PFC before expiry of T7. In case the timer T7 expires, the SGSN shall consider 
the create BSS PFC procedure terminated and failed. 
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The BSS shall report the outcome of the queuing for every queued PFC. The BSS shall stop the timer TIO associated to 
a given PFC when it has been successfully established or modified. The BSS shall then send a CREATE-BSS-PFC- 
ACK PDU with cause 'PFC created successfully' to the SGSN for that PFC, informing the SGSN of the negotiated 
ABQP. Upon receipt of the CREATE-BSS-PFC-ACK PDU with cause 'PFC created successfully' from the BSS, the 
SGSN shall stop timer T7. 

In the case the timer TIO expires, the create BSS PFC procedure terminates in the BSS for the corresponding PFC and 
the BSS shall send a CREATE-BSS-PFC-NACK PDU with cause 'PFC create failure'. The SGSN shall then consider 
the create BSS PFC procedure terminated and failed. 

In case the SGSN wishes to delete a PFC which is being queued, it shall stop timer T7 and start the delete BSS PFC 
procedure. Upon receipt of the request to delete the PFC, the BSS shall take it out from the queue and proceed with the 
rest of the procedure, as described in sub-clause 8a.3. 

In case the SGSN wishes to modify a PFC which is being queued, it shall restart timer T7 and send a CREATE-BSS- 
PFC PDU as described in sub-clause 8a. 1. Upon receipt of the request to modify the PFC, the BSS shall take it out from 
the queue and treat the new request. 

8a.1.1 Abnormal conditions 

If the SGSN receives a DOWNLOAD-BSS-PFC PDU with an unknown PFI it shall not respond with a CREATE-BSS- 
PFC PDU. 

If a CREATE-BSS-PFC PDU is not received for a DOWNLOAD-BSS-PFC PDU within T6 seconds, then the 
DOWNLOAD-BSS-PFC PDU shall be repeated a maximum of DOWNLOAD-BSS-PFC -RETRIES attempts. After 
DOWNLOAD-BSS-PFC -RETRIES + 1 attempts the procedure is stopped and the O&M system is informed. If a BSS 
PFC is not received then the BSS shall handle uplink and downlink transfers according to a best-effort default aggregate 
BSS QoS profile. 

If a CREATE-BSS-PFC-ACK or CREATE-BSS-PFC-NACK PDU is not received in response to a CREATE-BSS-PFC 
PDU within T7 seconds, then the CREATE-BSS-PFC PDU shall be repeated a maximum of CREATE-BSS-PFC- 
RETRIES attempts. After CREATE-BSS-PFC -RETRIESh-1 attempts the procedure is stopped and the O&M is 
informed. 

If a BSS not supporting ARP handling is unable to create the PFC then a CREATE-BSS-PFC-NACK PDU is returned 
with a cause value (e.g. Cause value: PFC create failure). The SGSN shall stop the Create BSS PFC procedure. 

If a BSS supporting ARP handling is unable to create the PFC immediately and the ARP IE was not present in the 
CREATE-BSS-PFC PDU or the ARP IE was present but queuing is not allowed for the PFC, then a CREATE-BSS- 
PFC-NACK PDU is returned with cause value 'PFC create failure'. The SGSN shall then stop the Create BSS PFC 
procedure. 

If a CREATE-BSS-PFC PDU is received in the BSS for an MS for which the PS Handover Required procedure is 
ongoing, the BSS shall ignore the CREATE-BSS-PFC PDU and return a CREATE-BSS-PFC-NACK PDU to the SGSN 
indicating Cause "MS under PS Handover treatment". 



8a.2 Modify BSS PFC procedure 



The BSS may request modification of the contents of an existing BSS PFC at any time via the MODIFY-BSS-PFC 
PDU, e.g. due to a change in resource availability at the BSS. The BSS sends the MODIFY-BSS-PFC PDU and start 
timer T8. The SGSN inserts the modified parameters in the MODIFY-BSS-PFC PDU into the relevant PDP contexts. 
The SGSN shall respond to a modify request with a MODIFY-BSS-PFC-ACK PDU except when there is an ongoing 
Delete BSS PFC procedure for that PFI (see sub-clause 8a. 3). The SGSN may restrict the requested aggregate BSS QoS 
profile given its capabilities and current load. The Packet Flow Timer (PET) may be provided to the BSS by the SGSN. 
This timer is (started or) restarted upon the receipt of the MODIFY-BSS-PFC-ACK PDU and restarted after the 
transmission of an uplink PDU for that PFC. On receipt of a response to the Modify procedure the BSS shall stop timer 
T8. 

The SGSN can reject the profile proposed by the BSS by answering with a MODIFY-BSS-PFC-ACK PDU containing 
the previous ABQP. The SGSN may request the modification of the contents of a BSS PFC at any time via the 
CREATE-BSS-PFC PDU, e.g. due to the activation, modification, or deactivation of a PDP context. It shall not use the 
MODIFY-BSS-PFC PDU. If the BSS PFC already exists the BSS shall interpret the PDU as a modification request and 
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the BSS shall reply with a CREATE-BSS-PFC-ACK. The ESS may restrict the requested ABQP given its capabilities 
and the current load. 

The Modify BSS PFC procedure shall never be initiated for an MS for which the PS Handover Required procedure is 
ongoing. 

8a.2.1 Abnormal conditions 

If a MODIFY-BSS-PFC-ACK is not received in response to a MODIFY-BSS-PFC PDU within T8 seconds, then the 
MODIFY -BSS-PFC PDU shall be repeated a maximum of MODIFY-BSS-PFC-RETRIES attempts. After 
MODIFY-BSS-PFC-RETRIES+1 attempts the procedure is stopped and the O&M is informed. 



8a.3 Delete BSS PFC procedure 



The SGSN may request the deletion of a BSS PFC at any time using the DELETE-BSS-PFC PDU. The BSS shall 
respond with a DELETE-BSS-PFC-ACK PDU. In case of user inactivity the BSS may delete a BSS packet flow context 
without notifying the SGSN. In case the BSS is no longer able to support the BSS PFC ABQP, it may send a DELETE- 
BSS-PFC-REQ PDU with cause "PFC pre-empted" or "ABQP no more supported" to the SGSN. The SGSN may either 
start the Delete BSS PFC procedure or a new Create BSS PFC procedure. In case the BSS receives neither a DELETE- 
BSS-PFC PDU nor a CREATE-BSS-PFC PDU the behaviour in the BSS is implementation specific. 

The Delete BSS PFC procedure takes precedence over the Modify BSS PFC and the Create BSS PFC procedures, i.e. 
when the BSS receives a DELETE-BSS-PFC PDU it shall abort any ongoing Create BSS PFC or Modify BSS PFC 
procedure for that PEL 

If a DELETE-BSS-PFC PDU is received for an MS for which the PS Handover Required procedure is ongoing, the 
BSS shall initiate the PS Handover Cancel procedure and continue the Delete BSS PFC procedure for the corresponding 
MS. 

8a.4 PS Handover Required procedure 

In the case of an intra-BSS PS Handover or intra-BSS DTM Handover, the optimized intra-BSS handover procedure 
may be used (see 3GPP TS 44.060); in such case, the PS Handover Required procedure is not used. 

When a BSS initiates a PS handover or DTM Handover it shall initiate the PS Handover Required procedure and send 
the PS-HANDOVER-REQUIRED PDU to the SGSN. Except in the case of DTM Handover, the BSS shall then start 
timer T12 (see NOTE). 

NOTE: The DTM Handover procedure is guarded at the source BSS by the BSSMAP timer T23 (see 3GPP TS 
48.008). 

If DTM Handover is ongoing and was initiated for a reason specific to the packet resources, or PS Handover is ongoing, 
the Cause IE of the PS -HANDOVER-REQUIRED PDU should be set to an appropriate value (e.g. "Uplink quality", 
"UpUnk strength", "Downlink quahty", "DownUnk strength", "Distance", "Better cell", "Traffic" or "O&M 
intervention"). 

NOTE: The radio related cause values are not applicable to the DTM Handover. 

If DTM Handover is ongoing, and was initiated for a reason specific to the dedicated resource, the Cause IE shall 
indicate "CS cause". 

The BSS should not initiate the PS handover required procedure in the case of an MOCN configuration if the Rerouting 
procedure is ongoing. 

The BSS shall not initiate the PS handover required procedure in case CS to PS SRVCC from GERAN to UTRAN or to 
E-UTRAN [25] is ongoing. The reception of a PS-HANDOVER-REQUIRED PDU will initiate the PS Handover 
Required procedure in the SGSN and the allocation of resources in the target system. 

If PS handover to A/Gb mode is required, the source BSS shall include the Source BSS to Target BSS Transparent 
Container IE and the Target Cell Identifier IE in the PS -HANDOVER-REQUIRED PDU. 
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If PS handover to lu mode is required, the source BSS shall include the Source to Target Transparent Container IE and 
the Target RNC Identifier IE in the PS-HANDOVER-REQUIRED PDU. The Source to Target Transparent Container 
IE shall be encoded as the Source RNC to Target RNC Transparent Container IE as specified in 3GPP TS 25.413 or 
3GPPTS 44.118. 

If PS handover to a UTRAN CSG cell or hybrid cell is required, the source BSS shall include the Source to Target 
Transparent Container IE, Target RNC Identifier IE and the CSG Identifier IE in the PS-HANDOVER-REQUIRED 
PDU. The source BSS shall set the value of the Cell Access Mode field in the CSG Identifier IE according to the 
information received from the MS through measurement reporting as defined in 3GPP TS 44.060. The Source to Target 
Transparent Container IE shall be encoded as the Source RNC to Target RNC Transparent Container IE as specified in 
3GPPTS 25.413. 

NOTE: In this specification: A CSG cell is a reported cell for which the access mode indicates 'Closed access 
mode' as defined in [39] and Hybrid Cell is a reported cell for which the access mode indicates 'Hybrid 
access mode' as defined in [39]. 

If PS handover to E-UTRAN is required, the source BSS shall include the Source to Target Transparent Container IE 
and the Target eNB Identifier IE or the Target RNC Identifier IE (carrying the Corresponding RNC -ID of the target 
eNB) in the PS-HANDOVER-REQUIRED PDU. The Source to Target Transparent Container IE shall be encoded as 
the Source eNB to Target eNB Transparent Container IE as specified in 3GPP TS 36.413. 

If PS handover to a E-UTRAN CSG cell or hybrid cell is required, the source BSS shall include the Source to Target 
Transparent Container IE, the Target eNB Identifier IE, Tracking Area Code IE and the CSG Identifier IE in the PS- 
HANDOVER-REQUIRED PDU. The source BSS shall set the value of the Cell Access Mode field in the CSG 
Identifier IE according to the information received from the MS through measurement reporting as defined in 3GPP TS 
44.060. The Source to Target Transparent Container IE shall be encoded as the Source eNB to Target eNB Transparent 
Container IE as specified in 3GPP TS 36.413. 

The Active PFCs List IE informs the SGSN about which PFCs that are active for the MS in the source cell at the time of 
sending the PS -HANDOVER-REQUIRED PDU. The concept of "Active PFCs" is defined in 3GPP TS 43.129. The 
Active PFCs List IE shall not contain any pre-defined PFIs. 

For DTM Handover to A/Gb mode, the source BSS shall include the CS Indication IE in the Source BSS to Target BSS 
Transparent Container IE. The contents of the CS Indication IE shall uniquely identify, for this MS, the handover 
attempt, and shall be identical to the contents of the PS Indication IE included in the BSSMAP HANDOVER 
REQUIRED message (see 3GPP TS 48.008). The Target Cell Identifier IE shall identify the same cell as the one 
specified in the Cell Identifier List (preferred) IE in the corresponding BSSMAP HANDOVER REQUIRED message 
(see 3GPP TS 48.008). 

For DTM Handover to UTRAN, the source BSS shall set the Number oflu Instances IE equal to 2 in the Source RNC to 
Target RNC Transparent Container IE (see 3GPP TS 25.413) 

When the resource allocation in the target system is complete, the SGSN shall send a PS-HANDOVER-REQUIRED- 
ACK PDU to the source BSS and end the PS Handover Required procedure. 

The Target BSS to Source BSS Transparent Container IE, or the Target to Source Transparent Container IE as received 
from the target system, shall be included in the PS-HANDOVER-REQUIRED-ACK PDU. 

Except in the case of DTM Handover, the source BSS shall, on reception of the PS-HANDOVER-REQUIRED-ACK 
PDU from the SGSN, stop timer T12, trigger the transmission of the PS HANDOVER COMMAND message towards 
the MS (as specified in 3GPP TS 44.060) and end the PS Handover Required procedure. In the case of DTM Handover, 
the PS Handover Required procedure is terminated when timer T23 is stopped for any reason or expires as specified in 
3GPP TS 48.008. The subsequent behaviour of the network is specified in 3GPP TS 48.008. 

In case of unsuccessful PS Handover, the source BSS shall be notified through the PS-HANDOVER-REQUIRED- 
NACK PDU. 

When the SGSN terminates the PS Handover Required procedure by sending a PS-HANDOVER-REQUIRED-NACK 
PDU to the source BSS, the Cause IE should be set to an appropriate value (e.g. "PEC create failure", "Cell traffic 
congestion", "Equipment failure", "O&M intervention" , "PS Handover Target not allowed" or "PS Handover not 
Supported in Target BSS or Target System"). 

Except in the case of DTM Handover, upon reception of a PS-HANDOVER-REQUIRED-NACK PDU from the SGSN, 
the source BSS shall stop timer T12 and terminate the ongoing PS Handover Required procedure. 
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For DTM Handover, the source BSS behaviour on receipt of a PS-HANDOVER-REQUIRED-NACK PDU is described 
as part of the Handover Required procedure (see 3GPP TS 48.008). 

The source BSS shall always include the 'Reliable Inter RAT Handover Info' indicator set to "l"in the PS- 
HANDOVER-REQUIRED-PDU when the target is a GERAN A/Gb mode BSS if the Inter RAT Handover Info IE is 
available and was received from the SGSN in a PS-HANDOVER-COMPLETE-ACK or a CREATE-BSS-PFC PDU or 
a PS-HANDOVER-REQUEST PDU with 'Reliable Inter RAT Handover Info Indicator' set to '1'. It shall be set to "0" 
otherwise. 

If the SGSN receives the CSG Identifier IE in the PS-HANDOVER-REQUIRED PDU and the Cell Access Mode field 
is set to 'CSG cell', it shall perform access control as specified in 3GPP TS29.060. If the MS is allowed to access the 
target cell, the SGSN shall continue the PS handover to the target side as specified in 3GPP TS 29.060. If the MS is not 
allowed to access the target cell, the SGSN shall send the PS-HANDOVER-REQUIRED-NACK PDU with the Cause 
IE set to 'Invalid CSG cell'to the source BSS. If the Cell Access Mode field in the CSG Identifier IE is set to 'Hybrid 
cell', the SGSN shall provide the CSG membership status of the MS and the CSG Id to the target side as specified in 
3GPP TS 29.060 . 

8a.4.1 Abnormal conditions 

Except in the case of DTM Handover, if timer TI2 expires in the source BSS and there has been no response from the 
SGSN to the PS -HANDOVER-REQUIRED PDU, the source BSS may initiate a new PS Handover Required procedure 
for the same mobile station, either directly or after first having cancelled the previous PS Handover Required procedure 
by initiating the PS Handover Cancel procedure with the value for the Cause IE set to "T12 expiry". 

NOTE: For the case of DTM Handover, the abnormal condition caused by the expiry of BSSMAP timer T23 is 
described in 3GPP TS 48.008. 

8a.5 PS Handover Request procedure 

The SGSN shall initiate the PS Handover Request procedure by sending a PS-HANDOVER-REQUEST PDU, 
including the N AS container for PS Handover corresponding to the PFCs to be set-up (except in the case of intra-SGSN 
PS handover), to the target BSS and starting timer T13. The PS-HANDOVER-REQUEST PDU shall be sent on the 
point-to-point BVC indicated by the target Cell identity received from the old system. 

On receipt of a PS-HANDOVER-REQUEST PDU containing a CS Indication IE (i.e. a DTM Handover procedure is 
ongoing), then the target BSS shall proceed as follows: 

- If the timer T24 (see 3GPP TS 48.008) is not running, then the target BSS shall start timer T24. 

- When both PS-HANDOVER-REQUEST PDU and BSSMAP HANDOVER REQUEST messages have been 
received and the contents of the CS Indication IE and PS Indication IE are identical, the target BSS shall stop 
timer T24 (see 3GPP TS 48.008), and, provided that a dedicated resource has been allocated (see 3GPP TS 
48.008), attempt to create a new BSS Context for the MS, create PFCs according to the received ABQP 
parameters and allocate TBF resources within the capabilities of the mobile station. 

On receipt of a PS-HANDOVER-REQUEST PDU which does not contain a CS Indication IE, the target BSS shall 
create a new BSS Context for the MS, create PFCs according to the received ABQP parameters and allocate TBFs for 
uplink and, if needed, for downlink transmission. 

The SGSN may include the Service UTRAN CCO (Cell Change Order) information element in the PS-HANDOVER- 
REQUEST PDU (relevant if the network initiated cell change order to UTRAN, network intitiated cell change order to 
E-UTRAN,PS handover to UTRAN or PS Handover to E-UTRAN procedures are used). If this information element is 
received in multiple PDUs (either DL-UNITDATA PDU(s), CREATE-BSS-PFC PDU(s) or PS-HANDOVER- 
REQUEST PDU(s)), the information element contained in the last received PDU shall take precedence. 

The SGSN receiving the Reliable Inter RAT Handover Info IE in the PS-HANDOVER-REQUIRED PDU shall forward 
this IE to the target BSS in the PS-HANDOVER-REQUEST PDU. 

The Packet Flow Timer (PFT) is provided to the target BSS by the SGSN for each corresponding PFC. It is defined as 
the maximum time the BSS may hold the PFC during periods of inactivity for a PFC. The timer is started upon the 
initiation of the PS Handover Complete procedure (see sub-clause 8a. 7) and restarted after the transmission of an uplink 
PDU for that PFC. The timer is also restarted upon the transfer of the corresponding PFC from an old to a new cell. 
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When resources have been successfully allocated by the target BSS, it shall send a PS-HANDOVER-REQUEST-ACK 
PDU to the SGSN. From this point in time, the target BSS shall be prepared to receive downlink LLC PDUs for the 
corresponding MS on the allocated resources. The target BSS shall also be prepared to receive uplink RLC data blocks 
or a PS HANDOVER ACCESS message upon successful MS access in the target cell (as specified in 3GPP TS 44.060). 

The PS-HANDOVER-REQUEST-ACK PDU shall include the Target BSS to Source BSS Transparent Container IE 
(see sub-clause n.3.79) which contains either a complete PS HANDOVER COMMAND message or, in the case of 
DTM Handover, a complete DTM HANDOVER COMMAND message. For the definition of the PS HANDOVER 
COMMAND and DTM HANDOVER COMMAND messages, see 3GPP TS 44.060. In addition, the BSS shall include 
in the Target BSS to Source BSS Transparent Container IE the SI/PSI Container IE (see sub-clause 1 1 .3.95b) if the PS 
Handover Indications IE indicating "SI/PSI requested" was present in the Source BSS to Target BSS Transparent 
Container of the incoming PS-HANDOVER-REQUEST PDU. In the case where the target cell supports network 
sharing and the MS Radio Access Capability information element included in the Source BSS to Target BSS 
Transparent Container received in the PS-HANDOVER-REQUEST PDU indicates MS supporting network sharing , 
the target BSS shall include in the SI/PSI messages sent to the source BSS (if included in the Target BSS to Source BSS 
Transparent Container) the same PLMN ID as the one receieved in the Target Cell Identifier IE in the PS- 
HANDOVER-REQUEST PDU. 

Upon reception of the PS-HANDOVER-REQUEST-ACK PDU, the SGSN shall stop timer T13, end the PS Handover 
Request procedure and start timer T14 for supervision of the PS Handover Complete procedure. 

The target BSS may choose to terminate the PS Handover Request procedure by sending a PS-HANDOVER- 
REQUEST-NACK PDU to the SGSN due to any of the following reasons: 

- A BSS Context could not be allocated for the MS; 

- None of the PFCs in the PFCs To Be Set-up List IE of the PS-HANDOVER-REQUEST PDU could be granted 
the requested QoS; 

- No uplink TBF could be allocated for the MS in the BVCI. 

In addition, the target BSS may choose to terminate the PS Handover Request procedure by sending a PS- 
HANDOVER-REQUEST-NACK PDU to the SGSN if at least one of the PFCs in the PFCs To Be Set-up List IE of the 
PS-HANDOVER-REQUEST PDU could not be granted the requested QoS and the Cause IE indicates a non-critical PS 
or DTM handover. 

NOTE: The cause values "Better cell", "Traffic" indicate a non-critical PS or DTM handover. 

When a PS-HANDOVER-REQUEST-NACK PDU has been sent, no knowledge of the MS should be kept by the target 
BSS. 

Except in case of an attempted DTM Handover, when the target BSS decides to terminate the PS Handover Request 
procedure by sending a PS-HANDOVER-REQUEST-NACK PDU to the SGSN, the Cause IE should be set to an 
appropriate value (e.g. "PFC create failure", "Cell traffic congestion", "Equipment failure" or "O&M intervention"). 

In the case of an attempted DTM Handover, if the target BSS has failed to allocate PS resources, it shall send a PS- 
HANDOVER-REQUEST-NACK PDU with cause "DTM Handover - PS Allocation failure" to the SGSN. The target 
BSS may continue with the corresponding Handover Resource Allocation procedure, allocating only a dedicated 
resource (see 3GPP TS 48.008). 

In the case of an attempted DTM Handover, if the target BSS does not allocate a CS resource, it shall not allocate any 
PS resources, and shall send a PS-HANDOVER-REQUEST-NACK PDU with cause "DTM Handover - No CS 
resource" to the SGSN. 

The SGSN may inform the BSS about the contents of SPID in the PS-HANDOVER-REQUEST PDU. In this case the 
SPID is stored in the BSS. 

8a.5.1 Abnormal conditions 

If there is no response from the target BSS to the PS-HANDOVER-REQUEST PDU before timer T13 expires, the 
SGSN shall initiate the Delete BSS PFC procedure for each of the PFCs in the PFCs to be Set-up List IE for the 
corresponding MS. 
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If the timer T24 (see 3GPP TS 48.008) expires and the target BSS has received a PS-HANDOVER-REQUEST PDU 
(i.e. no corresponding BSSMAP HANDOVER REQUEST message has been received) the target BSS shall terminate 
the PS Handover Request procedure by sending a PS-HANDOVER-REQUEST-NACK PDU to the SGSN with cause 
"DTM Handover - T24 expiry". 

If a PS-HANDOVER-REQUEST PDU is received which contains a CS Indication IE which corresponds to a DTM 
Handover attempt which was previously terminated for this MS, then the BSS shall terminate the PS Handover Request 
procedure by sending a PS-HANDOVER-REQUEST-NACK PDU to the SGSN with cause "DTM Handover - Invalid 
CS Indication IE". Any ongoing Handover Resource Allocation procedure (see 3GPP TS 48.008) for this mobile shall 
not be aborted in this case. 

NOTE: Other failure cases related to the expiry of the A interface timer T24 are described in 3GPP TS 48.008). 

If timer T14 expires before the SGSN receives a PS-HANDOVER-COMPLETE PDU, it shall initiate the Delete BSS 
PFC procedure for each allocated PFC (i.e. for each PEC included in the List of Set-up PFCs IE in the corresponding 
PS-HANDOVER-REQUEST-ACK PDU) towards the target BSS to release the resources allocated for all PFCs 
allocated for the MS. 

8a.6 PS Handover Complete procedure 

The target BSS shall initiate the PS Handover Complete procedure: 

in the case of PS Handover, on reception of the first correct RLC data block (sent in normal burst format as 
defined in 3GPP TS 44.060) from the MS in the target Cell; 

- in the case of DTM Handover, on receipt of an RR HANDOVER COMPLETE message on the main DCCH in 
the target cell (see 3GPP TS 44.018). 

The target BSS shall send a PS-HANDOVER-COMPLETE PDU to the SGSN. 

From this point in time, the target BSS shall be prepared to receive uplink LLC PDUs from the corresponding MS on 
the allocated resources. Uplink LLC PDUs shall be sent from the target BSS to the SGSN with the TLLI received 
through the PS Handover Request procedure. 

The target BSS supporting inter-RAT PS handover to UTRAN shall request the Inter RAT Handover Info IE from the 
SGSN upon successful PS handover completion in the following cases: 

PS handover from UTRAN to GERAN; in this case the BSS shall replace the Inter RAT Handover Info received 
from the source RNC with the new value received from the SGSN in the PS-HANDOVER-COMPLETE-ACK 
PDU. 

- PS handover from GERAN A/Gb mode if it received PS-HANDOVER-REQUEST PDU with Reliable Inter RAT 
Handover Info IE missing or set to '0'; in this case the BSS shall replace the Inter RAT Handover Info received 
from the source BSS with the new value received from the SGSN in the PS-HANDOVER-COMPLETE-ACK 
PDU. 

- PS handover from GERAN A/Gb mode if Ihe'INTER RAT HANDOVER INFO'i& missing in the Source BSS to 
Target BSS container. 

- PS handover from E-UTRAN if the 'INTER RAT HANDOVER INFO' is missing in the Source BSS to Target 
BSS container. 

A target BSS supporting inter-RAT PS handover to E-UTRAN and that is missing the E-UTRAN Inter RAT Handover 
Info upon successful PS handover shall request this IE from the SGSN by setting the request for provision of these 
inter-RAT capabilities in the PS -HANDOVER-COMPLETE PDU. 

At reception of the PS-HANDOVER-COMPLETE PDU, the SGSN shall stop timer T14 (if running) and 

in case of non-optimised intra-BSS or intra-SGSN inter-BSS PS Handover, initiate the Delete BSS PFC 
procedure(s) towards the source BSS for each PFC corresponding to the MS in the source cell as described in 
sub-clause 8a.3; or 
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in case of inter-SGSN PS Handover, send a Forward Relocation Complete message to the old SGSN (see 3GPP 
TS 29.060). The old SGSN shall initiate a Delete BSS PFC procedure for each PEG corresponding to the MS in 
the source cell towards the source BSS as described in sub-clause 8a. 3. 

8a.6.1 Abnormal conditions 

If the SGSN does not receive a PS -HANDOVER-COMPLETE PDU before timer T14 expires, it shall initiate the 
Delete BSS PFC procedure towards the target BSS to release the resources for all PECs allocated for the MS. 

If a PS-HANDOVER-COMPLETE PDU refers to an MS which is unknown in the SGSN, it shall be ignored. 

8a.7 PS Handover Cancel procedure 

The source BSS may at any time, up to the time when the PS HANDOVER COMMAND or DTM HANDOVER 
COMMAND message is sent to the MS (as defined in 3GPP TS 44.060), initiate the PS Handover Cancel procedure. 
The reasons for cancellation could e.g. be "T12 expiry", "MS back on old channel", "Not all requested PFCs created" or 
"CS cause". 

The source BSS shall initiate the PS Handover Cancel procedure if the cell change attempt fails and the MS returns to 
the old cell and sends either a PACKET CELL CHANGE FAILURE message as specified in 3GPP TS 44.060 (for PS 
Handover) or an RR HANDOVER FAILURE message as specified in 3GPP TS 44.018 (for DTM Handover) using the 
old radio resources. 

During the normal intra-BSS or inter-BSS PS Handover, the source BSS shall also initiate the PS Handover Cancel 
procedure if it detects the loss of radio contact with MS (see 3GPP TS 44. 060). The cause value in the PS- 
HANDOVER-CANCEL PDU shall be set to "Radio contact lost with MS". In the case of DTM Handover, the source 
BSS shall initiate the PS Handover Cancel procedure in the following additional cases defined in the list of Abnormal 
Cases for the Handover Required Indication procedure (see 3GPP TS 48.008): 

a) Timer T23 expires and the source BSS has received a PS-HANDOVER-REQUIRED-ACK PDU from the 
SGSN; 

b) The source BSS receives a PS-HANDOVER-REQUIRED-ACK PDU and a BSSMAP HANDOVER 
REQUIRED REJECT message (see 3GPP TS 48.008); 

c) If the DTM Handover is ongoing and T8 expires (see 3GPP TS 48.008). 
The cause value in the PS -HANDOVER-CANCEL PDU shall be set to: 

in case a) above: "DTM Handover - T23 expiry"; 

in case b) above: "DTM Handover - MSC error"; 

in case c) above: "Radio contact lost with MS". 

When the source BSS decides to cancel an ongoing PS handover or DTM Handover, it shall initiate the PS Handover 
Cancel procedure by sending a PS-HANDOVER-CANCEL PDU to the SGSN. The source BSS shall regard all 
procedures related to PS handover or DTM Handover for the given MS as terminated after having sent the PS- 
HANDOVER-CANCEL PDU to the SGSN. 

Upon reception of a PS -HANDOVER-CANCEL PDU, (in the case of Inter-SGSN PS handover or Inter-SGSN DTM 
handover) the SGSN shall initiate a Forward Relocation Cancel procedure according to 3GPP TS 29.060. 

Upon reception of a PS-HANDOVER-CANCEL PDU, (in the case of Intra-SGSN PS handover or Intra-SGSN DTM 
handover or Inter-RAT PS handover) the SGSN shall 

- in case of GERAN A/Gb mode to GERAN A/Gb mode PS/DTM handover, initiate the Delete BSS PFC 
procedure towards the target BSS to release the resource allocated for the MS. 

in case of GERAN A/Gb mode to UTRAN PS/DTM handover, initiate the lu Release procedure towards the 
target RNC to release the resource allocated for the UE (see 3GPP TS 25.413). 



£75/ 



3GPP TS 48.01 8 version 1 1 .3.0 Release 1 1 69 ETSI TS 1 48 01 8 V1 1 .3.0 (201 3-07) 

in case of GERAN A/Gb mode to E-UTRAN PS handover, initiate the Relocation Cancel procedure towards 
target MME which initiates the release of the resources allocated for the UE by the target eNB (see 3GPP TS 
36.413). 

NOTE: In case of cancellation due to CS call establishment, current behaviour regarding possible suspension of 
GPRS services applies after the PS Handover Cancel procedure is completed. 

8a.7.1 Abnormal conditions 

If a PS-HANDOVER-CANCEL PDU refers to an MS/UE which is unknown in the SGSN, it shall be ignored. 

An SGSN shall ignore a PS-HANDOVER-CANCEL PDU which refers to an MS for which the SGSN has already 
received a PS -HANDOVER-COMPLETE PDU from the target BSS (in the case of intra-SGSN PS handover) or a 
FORWARD RELOCATION COMPLETE message from the new SGSN (in the case of inter-SGSN PS handover). 



8b Signalling Procedures between LCS SAPs 
8b. 1 Location Procedure 

When the SGSN receives a location request, and the BSS supports LCS, the SGSN starts the location procedure by 
sending a PERFORM-LOCATION-REQUEST PDU. 

The SGSN shall provide the BVCI and the NSEI indicating the PTP functional entity (i.e. the cell) upon which the last 
LLC -PDU was received from the MS as well as the Cell ID received together with that LLC-PDU. The SGSN shall also 
provide the IMSI. If the SGSN has valid DRX Parameters for a TLLI, then the SGSN shall include them in the PDU. 

The Location Type indicates which type of location information the SGSN is requesting. The LCS capability IE reports 
the PS LCS capabilities of the MS and is included by the SGSN if it has been received from the MS. LCS Priority and 
LCS QoS are provided if available in the SGSN. The SGSN may provide the IMEI of the Mobile Station. 

On receipt of the PERFORM-LOCATION-REQUEST PDU for positioning of the target MS, the BSS transfers the 
positioning request to the SMLC according to the procedures defined in 3GPP TS 43.059 and 3GPP TS 49.031 and 
awaits the result. The BSS then returns the result of positioning to the SGSN in the PERFORM-LOCATION- 
RESPONSE PDU. This PDU contains the PTP BVCI indicating the PTP functional entity (i.e. the cell) upon which the 
last LLC-PDU was received from the MS, a location estimate and optionally positioning data. 

If assistance data was instead requested by the SGSN for an MS, the BSS transfers the request to the SMLC according 
to the procedures defined in 3GPP TS 43.059 and 3GPP TS 49.031 and awaits the result. If the Requested GPS or 
GANSS Assistance Data IE was received from the MS, it is forwarded to the BSS. If the SMLC indicates to the BSS 
that it was able successfully to transfer this to the MS, the BSS shall return a PERFORM-LOCATION-RESPONSE 
PDU to the SGSN. This PDU shall contain the PTP BVCI indicating the PTP functional entity (i.e. the cell) upon which 
the last LLC-PDU was received from the MS but no other optional or conditional information elements. The absence of 
an LCS Cause parameter in this case implies that the transfer was successful. 

Otherwise, if the deciphering keys were requested for LCS broadcast assistance data, the BSS transfers the request to 
the SMLC according to the procedures defined in 3GPP TS 43.059 and 3GPP TS 49.031 and awaits the result. If the 
BSS receives the deciphering keys, the BSS shall send them to the SGSN in a PERFORM-LOCATION-RESPONSE 
PDU containing also the PTP BVCI indicating the PTP functional entity (i.e. the cell) upon which the last LLC-PDU 
was received from the MS. 

8b.1.1 Unsuccessful Operation 

If the BSS fails to respond to the PERFORM-LOCATION-REQUEST PDU it returns a PERFORM-LOCATION- 
RESPONSE PDU with a LCS cause value indicating the failure cause. 

If the BSS receives a failure indication from the SMLC it shall send a PERFORM-LOCATION-RESPONSE PDU to 
the SGSN with the LCS cause value that it received from the SMLC. 
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8b. 1.2 Abnormal Conditions 

The following condition may occur: 

If the SGSN needs to abort previously initiated location request, it shall send the PERFORM-LOCATION- ABORT 
PDU to the BSS. This PDU shall include the FTP BVCI indicating the PTP functional entity (i.e. the cell) upon which 
the last LLC-PDU was received from the MS. As a result of reception of this PDU the BSS shall abort activities related 
to positioning of the target MS or assistance data delivery. The BSS shall return a PERFORM-LOCATION- 
RESPONSE PDU with a cause value indicating the abortion of location request. The SGSN may reattempt the 
positioning request after the PERFORM-LOCATION-RESPONSE PDU is received from the BSS, but not before the 
PDU is received. 

If the P-TMSI is reallocated for a target MS during the location procedure, the SGSN shall abort the location procedure. 

If a SUSPEND PDU is received for a target MS during the location procedure, the SGSN shall abort the location 
procedure. 

If a Routing Area Update request is received from a target MS during the location procedure, the SGSN shall abort the 
location procedure. 

If an Inter NSE Cell Change, within the same routing area, occurs for a target MS during the location procedure, the 
SGSN shall provide the new NSEI and new BVCI in the FLUSH-LL PDU sent to the BSS, in order for the BSS to 
maintain the on-going location procedure, if possible. In case the BSS is unable to maintain the on-going location 
procedure, then a location abort shall be triggered by the BSS towards the SMLC. 

8b. 1.3 Overload 

For location requests initiated by the SGSN, the BSC may employ the same procedures defined for an SMLC in 
3GPP TS 49.031 to alleviate an overload condition in the BSS. 

8b. 2 Position Command Procedure 

The position command procedure is used to convey an embedded RRLP message between the BSS and the MS. 

8b.2.1 Position Command 

The BSS initiates the position command procedure by sending the POSTION-COMMAND PDU to the SGSN. The 
procedure is only valid while a location procedure for the target MS is ongoing. 

The POSITION-COMMAND PDU shall include the RRLP Flags and the RRLP APDU information elements and the 
PTP BVCI indicating the PTP functional entity (i.e. the cell) upon which the last LLC-PDU was received from the MS. 
The RRLP APDU information element carries the RRLP message and the RRLP Flags information element carries 
control information for RRLP. 

The SGSN shall extract the RRLP message from the RRLP APDU information element and forward it, together with 
the RRLP Flags, to the MS in a TOM message carried in an LLC-PDU, see 3GPP TS 44.064. 



8b.2.2 Position Response 



The SGSN initiates the position response procedure when it receives a TOM message in an LLC-PDU carrying an 
RRLP message for a target MS. The procedure is only valid while a location procedure for the target MS is ongoing. 

When the SGSN receives a TOM message in an LLC-PDU carrying an RRLP message for a target MS, the SGSN shall 
extract the RRLP message and forward it to the BSS in a POSITION-RESPONSE PDU. The RRLP message shall be 
included in the RRLP APDU information element. The RRLP Flags information shall be extracted from the TOM 
header and be included in the RRLP Flags information element The POSITION-RESPONSE PDU shall also include the 
PTP BVCI indicating the PTP functional entity (i.e. the cell) upon which the last LLC-PDU was received from the MS. 
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8b.2.3 Unsuccessful Operation 



If the SGSN fails to process the POSITION-COMMAND PDU it returns a POSITION-RESPONSE PDU with a LCS 
cause value indicating the failure cause. 

If a POSITION-COMMAND PDU is received by the SGSN while a location procedure for the target MS is not ongoing 
a POSITION-RESPONSE PDU with a LCS cause value indicating this failure cause is returned. 

If a POSITION-RESPONSE PDU is received by the BSS while a location procedure for the target MS is not ongoing 
the BSS shall ignore the PDU. 



8c Signalling procedures between RIM SAPs 

8c. 1 General 
8C.1.1 Introduction 

The following sub-clauses describe the generic RAN Information Management (RIM) procedures which support the 
exchange of information, via the core network, between peer application entities located in a GERAN, in a UTRAN or 
in an E-UTRAN access network. 

The RIM function is performed through the interaction of the following sub-layers: 

the underlying part of BSSGP used to transport and route the RIM PDUs from a BSS to an SGSN or from an 
SGSN to a BSS over the Gb interface; 

the RIM protocol allowing the exchange of the information between two BSSs or between a BSS and an RNS or 
between a BSS and a eNodeB transparently through the core network; 

the application part on the top of the RIM protocol, referred to as the "RIM application" in this specification. 

NOTE: The functional split between the RIM application and the RIM protocol is provided for information in the 
present specification and should allow for various implementations. 

The PDUs conveying the RAN information between two RIM entities are including containers that shall not be 
interpreted by the core network nodes. The exchange of information is triggered by the application in a controlling BSS. 

The support of different applications is achieved by the appropriate definition of specific application containers for 
those applications. 

If the RAN Information Management (RIM) feature is supported by both the BSS and the SGSN, the RIM procedures 
can be used by any RIM application running on this BSS and requiring information transfer between two BSSs via the 
core network. 

NOTE: Specific requirements applicable to RIM between GERAN and UTRAN or between GERAN and E- 
UTRAN are specified in sub-clause 8c. 1.4. 

8C.1.2 Definitions 

8c.1 .2.1 Controlling and serving nodes 

The BSS requesting the information is called the "controlling BSS", the BSS providing the requested information is 
called the "serving BSS". Considering a pair of BSSs, each may be at the same time both a controlling BSS and a 
serving BSS. 

In the present specification the term "BSS" should be understood as "RNC or eNodeB" in the relevant situations (e. g. 
NACC from UTRAN/E-UTRAN to GERAN), unless it is explicitly stated otherwise. 
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8C.1.2.2 RIM association 

A RIM association links unambiguously either a cell in the serving BSS with the controlling BSS that has initiated an 
information request related to that cell for a given application, or a cell in the controlling BSS with the serving BSS that 
receives the RAN-INFORMATION-REQUEST PDU for a given application, and is identified by the following pieces 
of information: 

Controlling BSS identifier, or, for some particular values of the SON Transfer Application Identity for which the 
Reporting Cell Identifier is a cell in the controlling BSS (see TS 36.413 [36]), the serving BSS identifier. 

Cell Identifier in the serving BSS, or, for some particular values of the SON Transfer Application Identity (see 
TS 36.413 [36]), Cell Identifier in the controlling BSS. 

- RIM Application Identity 

SON Transfer Application Identity (only applicable if the RIM Application Identity indicates "SON Transfer"). 

8C.1.2.3 RIM variables 

In this protocol description, variables are used to represent the status of the relevant entity as a result of an event, such 
as the reception of an information element in a message. The variables serve the purpose of specifying an abstract 
model of the protocol entity, and do not therefore impose any particular implementation. 

The following variables are defined in the serving BSS: 

MULTIPLE_REPORTING_ONGOING: this variable indicates whether event-based multiple reporting is active 
or not for a given RIM association. This variable is initialised to FALSE prior to the reception of any request 
related to the corresponding association from the controlling BSS, then it is updated according to the relevant 
procedure requirements. 

- MULTIPLE_REPORT_SETTING_RSN: this variable stores the RSN of the last request having initiated or re- 
initiated multiple reporting in the serving BSS and is used as a reference to ascertain whether any further request 
received for this association is outdated or not. The value of this variable is only significant when multiple 
reporting is active (i.e. MULTIPLE_REPORTING_ONGOING set to TRUE). 

8c.1 .3 RIM PDUs description 

8C.1.3.1 RAN-INFORMATION-REQUEST PDU 

The RAN-INFORMATION-REQUEST PDU is used by the controlling BSS to request or interrupt an information 
transfer from a serving BSS. The RAN-INFORMATION-REQUEST PDU specifies the requested operation and the 
expected information when applicable. The following RAN-INFORMATION-REQUEST PDU type extensions are 
defined: 

- RAN-INFORMATION-REQUEST/Single Report is used to request a single report. 

- RAN-INFORMATION-REQUEST/Multiple Report is used to request event-driven multiple reports. 

- RAN-INFORMATION-REQUEST/Stop is used to stop event-driven multiple reports. 

8C.1.3.2 RAN-INFORMATION PDU 

The RAN-INFORMATION PDU is used by the serving BSS to transmit the requested information to the controlling 
BSS. The following RAN-INFORMATION PDU type extensions are defined: 

- RAN-INFORMATION/Single Report is used to acknowledge the reception of a RAN-INFORMATION- 
REQUEST/Single Report and to transmit the requested single report information. 

- RAN-INFORMATION/Initial Multiple Report is used to acknowledge the reception of a RAN- 
INFORMATION-REQUEST/Multiple Report and to transmit the initial report of the event-driven multiple 
reporting. 
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RAN-INFORMATION/Multiple Report is used to transmit subsequent reports while event-driven multiple 
reporting is active. 

- RAN-INFORMATION/Stop is used to acknowledge the reception of a RAN-INFORMATION-REQUEST/Stop. 

RAN-INFORMATION/End is used to indicate that the serving BSS will not longer send multiple reports for 
other reasons than the reception of a RAN-INFORMATION-REQUEST/Stop. 

8c.1 .3.3 RAN-INFORMATION-ACK PDU 

The RAN-INFORMATION-ACK PDU is used by the controlhng BSS to acknowledge the reception of a previous 
RAN-INFORMATION PDU if so requested by the serving BSS and is used by the serving BSS to acknowledge the 
reception of a previous RAN-INFORMATION-APPLICATION-ERROR PDU if so requested by the controlling BSS. 

8C.1.3.4 RAN-INFORMATION-ERROR PDU 

The RAN-INFORMATION-ERROR PDU is used, by either the controlling or the serving BSS, to report an error 
diagnosed at the RIM protocol level to the peer entity. 

8C.1.3.5 RAN-INFORMATION-APPLICATION-ERROR PDU 

The RAN-INFORMATION-APPLICATION-ERROR PDU is used by the controlling BSS to inform the peer 
application in the serving BSS about erroneous application information in a previously received RAN-INFORMATION 
PDU. 

8c.1 .4 RIM addressing and routing principles 

8c.1 .4.1 RIM routing address 

8c. 1 .4.1 .1 GERAN BSS identification 

As there is no BSS address identifier defined as such in the 3GPP specifications, RIM makes use of the cell identifier 
(RAI H- CI - see sub-clause 11. 3. 9 in the present document and 3GPP TS 23.003) of any cell parented by the BSS: 

the cell identifier of the source cell is used to identify the BSS issuing a RIM PDU; 

the cell identifier of the destination cell is used to identify the BSS towards which a RIM PDU is issued. 

The source cell identifying the BSS issuing a RAN-INFORMATION-REQUEST PDU may be chosen arbitrarily within 
all the cells parented by the controlling BSS. The deletion or the re-parenting of any cell used as a source cell in the 
controlling BSS shall trigger the actions described in sub-clause 8c. 5.2. 

8c. 1.4.1.2 UTRAN RNS identification 

When RIM is used to support the exchange of information with a peer application entity located in UTRAN, the RNC 
identifier (see sub-clause 11. 3. 70) shall be used as the RIM Routing Address (Source Cell Identifier or Destination Cell 
Identifier) to identify the corresponding RNS. 

Be. 1 .4.1 .3 E-UTRAN eNodeB identification 

When RIM is used to support the exchange of information with a peer application entity located in E-UTRAN, an eNB 
identifier (see sub-clause 1 1.3.70) shall be used as the RIM Routing Address (Source Cell Identifier or Destination Cell 
Identifier) to identify the corresponding eNodeB. 

8c.1 .4.2 Routing via the core network 

The RIM PDUs shall be conveyed transparently by the core network toward the destination BSS, RNS or eNodeB. A 
SGSN or MME shall use the destination address included in each RIM PDU either to send the PDU to the relevant BSS, 
RNS or eNodeB through the Gb, the lu or the SI interface respectively, or to tunnel the PDU towards the target SGSN 
or MME parenting the destination node through the Gn or S3 interface respectively. 
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If a RIM PDU has been tunnelled through the Gn or S3 interface to a destination SGSN or MME that does not support 
RIM the PDU is discarded without further action. 

8C.1.4.3 Address mirroring 

The following address mirroring principles shall be applied: 

the serving BSS shall mirror the Source Cell Identifier IE value and the Destination Cell Identifier IE value of 
the received RAN-INFORMATION-REQUEST PDU into the Destination Cell Identifier IE and the Source Cell 
Identifier \E, respectively, of the related RAN -INFORMATION PDU(s); 

the controlling BSS shall mirror the Source Cell Identifier IE value and the Destination Cell Identifier IE value 
of the RAN-INFORMATION PDU to be acknowledged into the Destination Cell Identifier IE and the Source 
Cell Identifier IE, respectively, of the related RAN-INFORMATION- ACK PDU; 

- the BSS having identified an error at the RIM protocol level in a received RAN-INFORMATION-REQUEST 
PDU, RAN-INFORMATION PDU, RAN -INFORMATION- ACK PDU or RAN-INFORMATION- 
APPLICATION-ERROR PDU shall mirror the Source Cell Identifier IE value and the Destination Cell 
Identifier IE value of the erroneous PDU into the Destination Cell Identifier IE and the Source Cell Identifier IE, 
respectively, of the RAN-INFORMATION-ERROR PDU; 

the controlling BSS having identified an error at application level in a received PDU shall mirror the Source Cell 
Identifier IE value and the Destination Cell Identifier IE value of the RAN-INFORMATION PDU which carried 
the erroneous application information into the Destination Cell Identifier IE and the Source Cell Identifier IE, 
respectively, of the RAN-INFORMATION-APPLICATION-ERROR PDU. 

8c.1 .5 In-order delivery and reliable transfer - RSN 
8C.1.5.1 General 

A BSS shall allocate a RIM Sequence Number (RSN) to any RAN-INFORMATION-REQUEST PDU, RAN- 
INFORMATION PDU or RAN-INFORMATION- APPLICATION-ERROR PDU sent by this BSS. The purpose of the 
RSN is twofold: 

- to assess whether a RAN-INFORMATION-REQUEST PDU or a RAN-INFORMATION PDU received for a 
given RIM association is providing up-to-date information or is outdated if having been overtaken by a PDU 
received previously; 

- to identify the PDU acknowledged with a RAN-INFORMATION-ACK PDU or reported in a RAN- 
INFORMATION-ERROR PDU. 

For the purpose of comparing any RSN value to a given RSN X, the RSN numbering space is halved in two equal parts 
(see figure 8c. 1) located on either sides of RSN X, the half part "below" RSN X (modulo RSN MAXh-1) defining the 
RSN values "older" than RSN X, the half part "above" (modulo RSN MAXh-1) RSN X defining the RSN values 
"newer" than RSN X. 
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RSNX 



RSN "older" than RSN X 



RSN "newer" than RSN X 



RSN MAX = 2**32-1 



Figure 8c.1 : Comparing RSN values 

8c.1 .5.2 Allocating RSN values at the sending BSS 

The RSN allocated to a RAN-INFORMATION-REQUEST PDU, RAN-INFORMATION PDU or RAN- 
INFORMATION-APPLICATION-ERROR PDU shall be greater (modulo 2**32) than the RSN value allocated to the 
previous PDU of the same type sent for this association. In case a given PDU needs to be resent, this PDU may be re- 
issued with either the same RSN value or an increased RSN value (modulo 2**32). 

NOTE: The RSN values allocated to two different PDUs sent successively for a given RIM association need not 
be consecutive (e.g. the RSN values could be uniquely allocated for a given application or within the 
whole BSS). However, in order to avoid RSN values depletion, the sending BSS should allocate the next 
higher RSN value (modulo 2**32) to the next PDU to be sent. 

To allow a receiving entity to assess whether two PDUs are received in the same relative order they have been sent or 
not, the difference between the RSN values allocated to those two PDUs should not exceed an RSN window size of 
2**31 (see sub-clause 8c. 1.5. 3). 

NOTE: In order to cope with RSN values outside the RSN window for a given RIM association, the relevant RIM 
procedures might be triggered on a timely basis for advancing the RSN window. 

8c.1 .5.3 Comparing RSN values at the receiving BSS 

Let PDUl and PDU2 be two PDUs received at the BSS and related to the same RIM association, PDUl is considered as 
having been sent earlier than PDU2 if the difference between the associated RSNs is less than an RSN window size of 
2**31 (see sub-clause 8c. 1.5.2), i.e.: 

(RSN2 - RSNl) mod (2**32) < 2**31 

8c.1 .6 RIM Protocol Version Number 

The RIM Protocol Version Number Information Element may be included in a RIM PDU. The RIM Protocol Version 
Number IE indicates which version of the RIM protocol is in use in the BSS having issued the PDU. If this Information 
Element is omitted, the behaviour of the receiving BSS should be the same as if the value of the RIM Protocol Version 
Number IE was "Version 1". 

Only "Version 1 " is defined in the present version of the specification. 

In case the protocol version of the receiving BSS is lower than the version of the sending BSS, and unless otherwise 
specified in the present specification, the general rules of the BSSGP protocol apply and any unknown parameter shall 
be ignored. 
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8c.2 RIM procedures 
8C.2.1 General 

The RAN Information Request procedure is initiated by an application in the controlling BSS when it either requires 
information or wants to stop the transmission of information from a remote peer entity of the same application in the 
serving BSS. The application on the controlling side indicates the type of operation (Multiple Reports, Single Report, 
Stop) to the peer entity. 

The RAN Information Send procedure is used to transfer application information between two entities of the same 
application in two BSSs via the core network. 

The RAN Information Application Error procedure is initiated by an application in the controlling BSS to transfer 
application error information to the peer application entity of the same application in the serving BSS. 

The RAN Information Error procedure is initiated by the RIM entity in the controlling or the serving BSS to transfer 
error information to the RIM entity in the peer BSS. 

8C.2.2 RAN Information Request procedure 

8C.2.2.1 RAN Information Request/Single Report procedure 



Controlling BSC 



Serving BSC 



RAN-INFORMATION-REQUEST/Single Report 



RAN-INFORMATION/Single Report 



Figure 8c.2.2.1 : RAN Information Request/Single Report Procedure 

8C.2.2.1 .1 Initiation by the controlling BSS 

Upon initiation of the procedure, the controlling BSS shall: 

1> set the content of the RAN-INFORMATION-REQUEST/Single Report PDU as follows: 

2> set the PDU type IE, the Destination Cell Identifier IE and the Source Cell Identifier IE; 

2> set the content of the RIM Container IE as follows: 

3> set the RIM Application Identity IE and the RIM Sequence Number IE; 

3> set the PDU Type Extension field in the RIM PDU Indications IE to "RAN-INFORMATION- 
REQUEST/Single Report"; 

3> set the RIM Protocol Version Number IE if necessary (see sub-clause 8c. 1 .6); 

3> include the Application Container IE according to the requirements of the application; 
1> send the RAN-INFORMATION-REQUEST/Single Report PDU; 
1> start T(RIR); 
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8C.2.2.1 .2 Reception of a valid RAN-INFORMATION-REQUEST/Single Report PDU by the 

serving BSS 

Upon reception of a valid RAN-INFORMATION-REQUEST/Single Report PDU as defined in sub-clause 8c.3.2 the 
serving BSS shall: 

1> set the content of the RAN-INFORMATION/Single Report PDU as follows: 

2> set the PDU type IE; mirror the Source Cell Identifier IE value and the Destination Cell Identifier IE value of 
the RAN-INFORMATION-REQUEST/Single Report PDU respectively into the Destination Cell Identifier 
IE and the Source Cell Identifier IE of the RAN-INFORMATION/Single Report PDU; 

2> set the content of the RIM Container IE as follows: 

3> set the RIM Application Identity IE as required by the application; 

3> set the RIM Sequence Number IE and, if necessary, the RIM Protocol Version Number IE (see sub-clause 
8c. 1.6); 

3> set the ACK indicator in the RIM PDU Indications IE to "No ACK requested"; 

3> set the PDU Type Extension field in the RIM PDU Indications IE to "RAN-INFORMATION/Single 
Report"; 

3> include either the RAN-INFORMATION Application Container IE or the Application Error Container 
IE according to the requirements of the application; 

1> send the RAN-INFORMATION/Single Report PDU to the controlling BSS. 

8C.2.2.1 .3 Reception of a valid RAN-INFORMATION/Single Report PDU by the controlling 

BSS 

Upon reception of a valid RAN-INFORMATION/Single Report PDU as defined in sub-clause 8c. 3.2 the controlling 
BSS shall: 

1> stop T(RIR) for this RIM association; 

1> deliver the relevant information to the application; 

and the procedure ends. 



8C.2.2.1.4 



Expiration of T(RIR) in the controlling BSS 



If T(RIR) expires the controlling BSS shall as an implementation option either inform the application that the procedure 
has failed or restart the RAN Information Request/Single Report procedure a finite number of times as described in sub- 
clause 8c. 2. 2. 1.1. 

8C.2.2.2 RAN Information Request/Multiple Report procedure 



Controlling BSC 



Servino BSC 



RAN-INFORMATION-REQUEST/Multiple Report 



RAN-INFORMATION/Multiple Report-Initial 



Figure 8c.2.2.2: Successful RAN Information Request/Multiple Report Procedure 
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8C.2.2.2.1 Initiation by the controlling BSS 

Upon initiation of the procedure, the controlHng BSS shall: 

1> set the content of the RAN-INFORMATION-REQUEST/Multiple Report PDU as follows: 

2> set the PDU type IE, the Destination Cell Identifier IE and the Source Cell Identifier IE; 

2> set the content of the RIM Container IE as follows: 

3> set the RIM Application Identity IE and the RIM Sequence Number IE; 

3> set the PDU Type Extension field in the RIM PDU Indications IE to "RAN-INFORMATION- 
REQUEST/Multiple Report"; 

3> set the RIM Protocol Version Number IE if necessary (see sub-clause 8c. 1.6); 

3> include the Application Container IE according to the requirements of the application; 
1> send the RAN-INFORMATION-REQUEST/Multiple Report PDU; 
1> Start T(RIR); 

8C.2.2.2.2 Reception of a valid RAN-INFORMATION-REQUEST/Multiple Report PDU by the 

serving BSS 

Upon reception of a vahd RAN-INFORMATION-REQUEST/Multiple Report PDU as defined in sub-clauses 8c.3.2 the 
serving BSS shall: 

1> if MULTIPLE_REPORTING_ONGOING is set to TRUE for this RIM association and if the received RAN- 
INFORMATION-REQUEST/Multiple Report PDU is considered as having been sent earlier (see sub-clause 
Bel .5) than the PDU whose RSN is stored in MULTIPLE_REPORT_SETTING_RSN, then: 

2> discard the PDU without further actions and the procedure ends; 

1> otherwise: 

2> set the MULTIPLE_REPORTING_ONGOING variable to TRUE for this RIM association; 

2> store the RIM Sequence Number IE value of the received PDU in the 
MULTIPLE_REPORT_SETTING_RSN variable; 

2> set the content of the RAN-INFORMATION/Initial Multiple Report PDU as follows: 

3> set the PDU type IE; mirror the Source Cell Identifier IE value and the Destination Cell Identifier IE 
value of the RAN-INFORMATION-REQUEST/Multiple Report PDU respectively into the Destination 
Cell Identifier IE and the Source Cell Identifier IE of the RAN-INFORMATION/Initial Multiple Report 
PDU; 

3> set the content of the RIM Container IE as follows: 

4> set the RIM Application Identity IE as required by the application; 

4> set the RIM Sequence Number IE and, if necessary, the RIM Protocol Version Number IE (see sub- 
clause 8c. 1.6); 

4> set the ACK indicator in the RIM PDU Indications IE to "No ACK requested"; 

4> set the PDU Type Extension field in the RIM PDU Indications IE to "RAN-INFORMATION/Initial 
Multiple Report"; 

4> include either the RAN-INFORMATION Application Container IE or the Application Error 
Container IE according to the requirements of the application; 

2> send the RAN-INFORMATION/Initial Multiple Report PDU. 
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8C.2.2.2.3 Reception of a valid RAN-INFORMATION PDU/lnitial Multiple Report PDU by the 

controlling BSS 

Upon reception of a valid RAN-INFORMATION/Initial Multiple Report PDU as defined in sub-clause 8c.3.2 the 
controlling BSS shall: 

1> stop T(RIR) for this RIM association; 

1> deliver the relevant information to the application; 

and the procedure ends. 



8C.2.2.2.4 



Expiration of T(RIR) in the controlling BSS 



If T(RIR) expires the controlling BSS shall as an implementation option either inform the application that the procedure 
has failed or restart the RAN Information Request/Multiple Report procedure a finite number of times as described in 

sub-clause 8c.2.2.2.1. 

8C.2.2.3 RAN Information Request/Stop procedure 



Controlling BSC 



Serving BSC 



RAN-INFORIVIATION-REQUEST/Stop 



RAN-INFORIVIATION/Stop 



Figure 8c.2.2.3: RAN Information Request/Stop Procedure 

8C.2.2.3.1 Initiation by the controlling BSS 

Upon initiation of the procedure, the controlling BSS shall: 

1> set the content of the RAN-INFORMATION-REQUEST/Stop PDU as follows: 

2> set the PDU type IE, the Destination Cell Identifier IE and the Source Cell Identifier IE; 

2> set the content of the RIM Container IE as follows: 

3> set the RIM Application Identity IE and the RIM Sequence Number IE; 

3> set the PDU Type Extension field in the RIM PDU Indications IE to "RAN-INFORMATION- 
REQUEST/Stop"; 

3> set the RIM Protocol Version Number IE if necessary (see sub-clause 8c. 1 .6); 

3> include the Application Container IE according to the requirements of the application; 

1> send the RAN-INFORMATION-REQUEST/Stop PDU; 

1> start T(RIR). 

8C.2.2.3.2 Reception of a valid RAN-INFORMATION-REQUEST/Stop PDU by the serving 

BSS 

Upon reception of a valid RAN-INFORMATION-REQUEST/Stop PDU as defined in sub-clause 8c.3.2, the serving 
BSS shall: 
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1> if MULTIPLE_REPORTING_ONGOING is set to TRUE for this RIM association and if the received RAN- 
INFORMATION-REQUEST/Stop PDU is considered as having been sent eariier (see sub-clause 8c. 1.5) than the 
PDU whose RSN is stored in MULTIPLE_REPORT_SETTING_RSN, then: 

2> discard the PDU without further actions and the procedure ends; 

1> otherwise: 

2> set the MULTIPLE_REPORTING_ONGOING variable to FALSE for this RIM association; 

2> set the content of the RAN-INFORMATION/Stop as follows: 

3> set the PDU type IE; mirror the Source Cell Identifier IE value and the Destination Cell Identifier IE 
value of the RAN-INFORMATION-REQUEST/Stop PDU respectively into the Destination Cell 
Identifier IE and the Source Cell Identifier IE of the RAN-INFORMATION/Stop PDU; 

3> set the content of the RIM Container IE as follows: 

4> set the RIM Application Identity IE as required by the application; 

4> set the RIM Sequence Number IE and, if necessary, the RIM Protocol Version Number IE (see sub- 
clause 8c. 1.6); 

4> set the ACK indicator in the RIM PDU Indications IE to "No ACK requested"; 

4> set the PDU Type Extension field in the RIM PDU Indications IE to "RAN-INFORMATION/Stop"; 

4> include either the Application Container IE or the Application Error Container IE according to the 
requirements of the application; 

2> send the RAN-INFORMATION/Stop PDU. 
8C.2.2.3.3 Reception of a valid RAN-INFORMATION/Stop PDU by the controlling BSS 

Upon reception of a vaUd RAN-INFORMATION/Stop PDU as defined in sub-clause 8c. 3.2 the controlhng BSS shall: 

1> stop T(RIR) for this RIM association; 

1> deliver the relevant information to the application; 
and the procedure ends. 

8C.2.2.3.4 Expiration of T(RIR) in the controlling BSS 

If T(RIR) expires the controlling BSS shall as an implementation option either inform the application that the procedure 
has failed or restart the RAN Information Request/Stop procedure a finite number of times as described in sub-clause 
8C.2.2.3.1. 
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8C.2.3 RAN Information Send procedure 



Controlling BSC 



Serving BSC 



RAN-INFORMATION/IVIultiple Report or /End 



RAN-INFORMATION-ACK 



Fig 8C.2.3: Acknowledged RAN Information Send procedure 

8C.2.3.1 Initiation by the serving BSS 

If multiple reporting has been requested for a given RIM association (i.e. the MULTIPLE_REPORTING_ONGOING 
variable is set to TRUE), the RAN Information Send procedure is initiated by the application in the serving BSS either 
to send updated information (using the RAN-INFORMATION/Multiple Report PDU) or to indicate that multiple 
reporting has been deactivated on the serving BSS side (using the RAN-INFORMATION/End PDU). 

Upon initiation of the procedure, the serving BSS shall: 

1> set the content of the RAN-INFORMATION PDU as follows: 

2> set the PDU type IE, mirror the Source Cell Identifier IE value and the Destination Cell Identifier IE value of 
the RAN-INFORMATION-REQUEST/Multiple Report PDU that is identified by the RSN stored in the 
MULTIPLE_REPORT_SETTING_RSN variable respectively into the Destination Cell Identifier IE and the 
Source Cell Identifier IE of the RAN-INFORMATION PDU; 

2> set the content of the RIM Container IE as follows: 

3> mirror the RIM Application Identity IE value of the RAN-INFORMATION-REQUEST/Multiple Report 
PDU that is identified by the RSN stored in the MULTIPLE_REPORT_SETTING_RSN variable into the 
RIM Application Identity IE of the RAN-INFORMATION PDU; 

3> set the RIM Sequence Number IE and, if necessary, the RIM Protocol Version Number IE (see sub-clause 
8C.1.6); 

3> set the PDU Type Extension field in the RIM PDU Indications IE to "RAN-INFORMATION/Multiple 
Report" or "RAN-INFORMATION/End" as required by the application; 

3> for a RAN-INFORMATION/Multiple Report PDU, set the ACK indicator to the value required by the 
application; for a RAN-INFORMATION/End PDU, set the ACT*: indicator to "ACK requested"; 

3> set the Application Container IE according to the requirements of the application; 

1> if the RAN-INFORMATION PDU is a RAN-INFORMATION/End (multiple reporting deactivated), set the 
MULTIPLE_REPORTING_ONGOING variable to FALSE; 

1> send the RAN-INFORMATION PDU; 

1> if the ACK indicator has been set to "ACK requested", start a T(RI) instance for this RAN-INFORMATION 
PDU; 

1> otherwise the procedure ends. 
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8C.2.3.2 Reception of a valid RAN-INFORMATION PDU by the controlling BSS 

Upon reception of a valid RAN-INFORMATION/Multiple Report or RAN-INFORMATION/End PDU as defined in 
sub-clause 8c. 3. 2 the controlling BSS shall: 

1> deliver the relevant information to the application; 

1> if the ACK indicator in the RIM PDU Indications IE included in the RIM container of the RAN- 
INFORMATION PDU is set to "ACK requested", the controlling BSS shall: 

2> set the content of the RAN-INFORMATION- ACK PDU as follows: 

3> set the PDU type IE; mirror the Source Cell Identifier IE value and the Destination Cell Identifier IE 
value of the RAN-INFORMATION PDU respectively into the Destination Cell Identifier IE and the 
Source Cell Identifier IE of the RAN-INFORMATION-ACK PDU; 

3> set the content of the RIM Container IE as follows: 

4> mirror the RIM Sequence Number IE value and the RIM Application Identity IE value included in the 
RIM container of the RAN-INFORMATION PDU respectively into the RIM Sequence Number IE 
and the RIM Application Identity IE of the RAN-INFORMATION-ACK PDU; 

4> set, if necessary, the RIM Protocol Version Number IE (see sub-clause 8c. 1.6); 

NOTE: If the RAN-INFORMATION PDU is a RAN-INFORMATION/End, the controlUng BSS shall consider 
that multiple reporting is deactivated for this RIM association in the serving BSS. 

2> send the RAN-INFORMATION-ACK PDU. 

1> otherwise, the procedure ends. 

8C.2.3.3 Reception of a valid RAN-INFORMATION-ACK PDU in the serving BSS 

Upon reception of a valid RAN-INFORMATION-ACK PDU as defined in sub-clause 8c.3.2 the serving BSS shall: 

1> if the RIM Sequence Number IE value contained in the RAN-INFORMATION-ACK PDU matches the RSN of 
the RAN-INFORMATION PDU having initiated the procedure then: 

2> stop the T(RI) instance corresponding to the acknowledged PDU; 

and the procedure ends. 

8C.2.3.4 Expiration of T(RI) in the serving BSS 

Upon expiration of the T(RI) instance the serving BSS shall, as an implementation option, either inform the application 
that the procedure has failed or restart the RAN Information Send procedure a finite number of times as described in 

sub-clause 8c.2.3.1. 
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8C.2.4 RAN Information Application Error procedure 



Controlling BSC 



Serving BSC 



RAN-INFORIVIATION-APPLICATION-ERROR 



RAN-INFORMATION-ACK 



Fig 8C.2.4: RAN Information Application Error procedure 
8C.2.4.1 Initiation by the controlling BSS 

Upon initiation of the procedure, the controlHng BSS shall: 

1> set the content of the RAN-INFORMATION- APPLICATION-ERROR PDU as follows: 

2> set the PDU type IE, mirror the Source Cell Identifier IE value and the Destination Cell Identifier IE value of 
the RAN-INFORMATION PDU with the erroneous application container respectively into the Destination 
Cell Identifier IE and the Source Cell Identifier IE of the RAN-INFORMATION- APPLICATION-ERROR 
PDU; 

2> set the content of the RIM Container IE as follows: 

3> set the RIM Application Identity IE and the RIM Sequence Number IE; 

3> set the RIM Protocol Version Number!^ if necessary (see sub-clause 8c. 1.6); 

3> set the ACK indicator in the RIM PDU Indications IE according to the requirements of the application; 

3> include the Application Error Container IE according to the requirements of the application 

1> send the RAN-INFORMATION-APPLICATION-ERROR PDU to the serving BSS; 

1> if the ACK indicator has been set to "ACK requested", start a T(RIAE) instance for this RAN-INFORMATION- 
APPLICATION-ERROR PDU; 

1> otherwise the procedure ends. 

8C.2.4.2 Reception of a valid RAN-INFORMATION-APPLICATION-ERROR PDU by 

the serving BSS 

Upon reception of a vahd RAN-INFORMATION-APPLICATION-ERROR PDU as defined in sub-clause 8c.3.2 the 
serving BSS shall: 

1> deliver the relevant information to the application; 

1> if the ACK indicator in the RIM PDU Indications IE included in the RIM container of the RAN- 

INFORMATION-APPLICATION-ERROR PDU is set to "ACK requested", then the serving BSS shall: 

2> set the content of the RAN-INFORMATION-ACK PDU as follows: 

3> set the PDU type IE, mirror the Source Cell Identifier IE value and the Destination Cell Identifier IE 
value of the RAN -INFORMATION-APPLICATION-ERROR PDU respectively into the Destination Cell 
Identifier IE and the Source Cell Identifier IE of the RAN-INFORMATION-ACK PDU; 

3> set the content of the RIM Container IE as follows: 
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4> mirror the RIM Sequence Number IE value and the RIM Application Identity IE value included in the 
RIM container of the RAN -INFORMATION-APPLICATION-ERROR PDU respectively into the 
RIM Sequence Number IE and the RIM Application Identity IE of the RAN-INFORMATION-ACK 
PDU; 

4> set the RIM Protocol Version Number IE if necessary (see sub-clause 8c. 1 .6); 

2> send the RAN-INFORMATION-ACK PDU. 

1> otherwise, the procedure ends. 

8C.2.4.3 Reception of a valid RAN-INFORMATION-ACK PDU by the controlling BSS 

Upon reception of a vaUd RAN-INFORMATION-ACK PDU as defined in sub-clause 8c.3.2, the controlhng BSS shall: 

1> if the RIM Sequence Number IE value contained in the RAN-INFORMATION-ACK PDU matches the RSN of 
the RAN-INFORMATION- APPLICATION-ERROR PDU having initiated the procedure 

2> then stop the T(RJAE) instance corresponding to the acknowledged PDU; 

1> else discard the PDU without further action; 

and the procedure ends. 

8C.2.4.4 Expiration of T(RIAE) in the controlling BSS 

At the expiration of the T(RIAE) instance corresponding to the RAN-INFORMATION- APPLICATION-ERROR PDU 
sent previously by the controlling BSS, the controlling BSS shall, as an implementation option, either inform the 
application that the procedure has failed or restart the RAN Information Application Error procedure a finite number of 
times as described in sub-clause 8c.2.4.L 



8C.2.5 RAN Information Error procedure 



Controlling/Serving 
BSC 




Serving/Controlling 
BSC 






RIM procedure 








RAN-INFORMATION-ERROR 















Fig 8C.2.5: RAN Information Error procedure 

The RAN Information Error procedure is initiated by the RIM in the source BSS (controlling or serving) to transfer 
error information to the RIM entity in the associated BSS; 

The procedure is described in sub-clause 8c. 3.4. 

8c.3 Abnormal conditions 
8C.3.0 General 

Two levels of abnormal conditions are defined for the RIM function: 

the abnormal conditions encountered at the BSSGP level as described in sub-clause 8c. 3. 1, affecting the routing 
mechanisms and the related lEs in the RIM PDUs; 
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the abnormal conditions encountered in the RIM container as described in sub-clauses 8c. 3. 2 and 8c. 3. 3. 

The errors encountered in the application container are handled by the application and are made known to the peer 
application entity by including the Application Error container IE. 

8C.3.1 Abnormal conditions at tiie BSSGP level 
8C.3.1.1 General 

The general protocol error handling as defined in section 9 applies. 

However, the RIM containers being defined as general containers for passing field elements transparently between 
BSSs via the core network are not subject to error handling at the BSSGP level but only at the RIM protocol level (see 
sub-clause 8c. 3. 2). 

Additionally the abnormal conditions defined in the following sub-clauses apply. 

8C.3.1 .2 RIM addressing error in BSS 

If a BSS receives from an SGSN a RIM PDU with a Destination Cell Identifier IE value which does not match the cell 
identifier of any of its parented cells, the PDU shall be discarded and a STATUS PDU with the cause value set to 
"Unknown Destination address" shall be sent back to the SGSN. 

8C.3.1 .3 RIM addressing error in the CN 

If an SGSN receives from a BSS a RIM PDU with an invalid destination address, the PDU shall be discarded and a 
STATUS PDU with the cause value set to "Unknown Destination address" shall be sent back to the BSS. 

8C.3.1 .4 RIM PDU addressed to a BSS not supporting RIM 

If an SGSN receives a RIM PDU addressed to a parented BSS that does not support the RIM procedures, the PDU shall 
be discarded without further action. 

8C.3.2 Abnormal conditions encountered in the RIM container 
8C.3.2.1 Unknown RIM Application Identity 

If the RIM container included in a RAN -INFORMATION PDU, RAN-INFORMATION-REQUEST PDU, RAN- 
INFORMATION-ACK PDU or RAN-INFORMATION-APPLICATION-ERROR PDU contains an unknown value in 
the RIM Application Identity IE, or if the RIM container contains an unknown value in the SON Transfer Application 
Identity IE in case the RIM Application Identity IE is set to "SON Transfer", or if the RIM application is disabled when 
receiving a RAN-INFORMATION-REQUEST PDU, the BSS shall send a RAN-INFORMATION-ERROR PDU with 
the RIM Cause IE set to "Unknown RIM Application Identity or RIM application disabled" back to the originating BSS 
(see sub-clause 8c. 3.4. 2) and discard the received PDU. 

If the RIM container included in a RAN-INFORMATION-ERROR PDU contains an unknown value in the RIM 
Application Identity IE, or if the RIM container contains an unknown value in the SON Transfer Application Identity IE 
in case the RIM Application Identity IE is set to "SON Transfer", the BSS shall discard the RIM PDU without further 
action. 

8C.3.2.2 Erroneous PDU Type Extension field 

If the PDU Type Extension field in the RIM PDU Indications IE included in the RIM container of a RAN- 
INFORMATION-REQUEST PDU does not indicate "RAN-INFORMATION-REQUEST/Multiple Report", "RAN- 
INFORMATION-REQUEST/Stop" or "RAN-INFORMATION-REQUEST/Single Report", the serving BSS shall send 
a RAN-INFORMATION-ERROR PDU containing the complete received PDU and with the RIM Cause IE set to "PDU 
not compatible with the feature set" back to the originating BSS (see sub-clause 8c. 3.4.2) and shall discard the received 
PDU. 
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If the PDU Type Extension field in the RIM PDU Indications IE included in the RIM container of a RAN- 
INFORMATION PDU does not indicate "RAN-INFORMATION/Single Report", "RAN-INFORMATION/Multiple 
Report", "RAN-INFORMATION/Initial Multiple Report", "RAN-INFORMATION/Stop" or "RAN- 
INFORMATION/End", the serving BSS shall send a RAN-INFORMATION-ERROR PDU containing the complete 
received PDU and with the RIM Cause IE set to "PDU not compatible with the feature set" back to the originating BSS 
(see sub-clause 8c. 3.4. 2) and shall discard the received PDU. 

8C.3.2.3 Missing conditional IE 

If an expected conditional Information Element is not included in the RIM container of a RAN-INFORMATION PDU, 
RAN-INFORMATION-REQUEST PDU, RAN-INFORMATION-ACK PDU or RAN-INFORMATION- 
APPLICATION-ERROR PDU, the BSS shall send a RAN-INFORMATION-ERROR PDU containing the complete 
received PDU and with the RIM Cause IE set to "Missing Conditional IE" back to the originating BSS (see sub-clause 
8c. 3.4.2) and discard the received PDU. 

If an expected conditional Information Element is not included in the RIM container of a RAN-INFORMATION- 
ERROR PDU, the BSS shall discard the received PDU without further action. 

8C.3.2.4 Missing mandatory IE 

If a mandatory Information Element is not included in the RIM container of a RAN-INFORMATION PDU, RAN- 
INFORMATION-REQUEST PDU, RAN-INFORMATION-ACK PDU or RAN-INFORMATION-APPLICATION- 
ERROR PDU, the BSS shall send a RAN-INFORMATION-ERROR PDU containing the complete received PDU and 
with the RIM Cause IE set to "Missing Mandatory IE" back to the originating BSS (see sub-clause 8c. 3.4.2) and discard 
the received PDU. 

If a mandatory Information Element is not included in the RIM container of a RAN-INFORMATION-ERROR PDU, 
the BSS shall discard the received PDU without further action. 

8C.3.2.5 Syntactical error in an expected conditional IE 

If a syntactical error is detected in an expected conditional Information Element included in the RIM container of a 
RAN-INFORMATION PDU, RAN-INFORMATION-REQUEST PDU, RAN-INFORMATION-ACK PDU or RAN- 
INFORMATION-APPLICATION-ERROR PDU, the BSS shall send a RAN-INFORMATION-ERROR PDU 
containing the complete received PDU and with the RIM Cause IE set to "Conditional IE error" back to the originating 
BSS (see sub-clause 8c. 3.4. 2) and discard the received PDU. 

If a syntactical error is detected in an expected conditional Information Element included in the RIM container of a 
RAN-INFORMATION-ERROR PDU, the BSS shall discard the received PDU without further action. 

8C.3.2.6 Syntactical error in a mandatory IE 

If a syntactical error is detected in a mandatory IE included in the RIM container of a RAN-INFORMATION PDU, 
RAN-INFORMATION-REQUEST PDU, RAN-INFORMATION-ACK PDU or RAN-INFORMATION- 
APPLICATION-ERROR PDU, the BSS shall send a RAN-INFORMATION-ERROR PDU containing the complete 
received PDU and with the RIM Cause IE set to "Invalid mandatory information" back to the originating BSS (see sub- 
clause 8c. 3.4. 2) and discard the received PDU. 

For this rule the following exceptions apply: 

unknown RIM Application Identity IE (see sub-clause 8c. 3. 2.1); or 

erroneous PDU Type Extension field (see sub-clause 8c. 3. 2. 2) 

If a syntactical error is detected in a mandatory IE included in the RIM container of a RAN-INFORMATION-ERROR 
PDU, the BSS shall discard the received PDU without further action. 

8C.3.2.7 Unexpected conditional IE 

If an unexpected conditional Information Element is received in the RIM container of a RAN-INFORMATION PDU, 
RAN-INFORMATION-REQUEST PDU, RAN-INFORMATION-ACK PDU or RAN-INFORMATION- 
APPLICATION-ERROR PDU, the BSS shall send a RAN-INFORMATION-ERROR PDU containing the complete 
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received PDU and with the RIM Cause IE set to "Unexpected Conditional IE" back to the originating BSS (see sub- 
clause 8c. 3. 4. 2) and discard the received PDU. 

If an unexpected conditional Information Element is received in the RIM container of a RAN-INFORMATION- 
ERROR PDU, the BSS shall discard the received PDU without further action. 

8C.3.2.8 Containers with out-of-sequence information elements 

The receiving BSS may accept RIM containers that include information elements that do not appear to be in the correct 
sequence. Elements that occur more than once in a RIM container shall be assumed to have been transmitted in the 
correct order. Recipients that do not accept out of sequence information elements shall regard the RIM container as 
containing unexpected and/or missing information elements and follow the procedures defined in the rest of this sub- 
clause 8c. 3. 2. 

8C.3.2.9 Container with semantically incorrect content 

When any IE with semantically incorrect contents is received within a RIM container, the receiving BSS shall react 
according to the relevant protocol specification. If however no such reactions are specified, the receiving BSS shall 
ignore that IE and treat the rest of the RIM container. If the rest of the RIM container can no longer be handled because 
this IE was ignored then the receiving BSS shall send a RAN-INFORMATION-ERROR PDU containing the complete 
received PDU and with the RIM Cause IE set to "Semantically incorrect PDU" back to the originating BSS (see sub- 
clause 8c. 3. 4. 2) and discard the received PDU. 

8C.3.3 Unexpected RIM PDU 

If a BSS receives a RIM PDU in a case not covered by the RIM procedures specified in sub-clause 8c. 2, it shall discard 
the RIM PDU without further action. 

8C.3.4 RIM error reporting 
8C.3.4.1 General 

A BSS diagnosing any of the abnormal cases identified in sub-clause 8c. 3. 2 in a received RIM PDU shall inform the 
originating BSS by sending in return a RAN-INFORMATION-ERROR PDU as described in sub-clause 8c.3.4.2. 

The tasks to be performed upon reception of the RAN-INFORMATION-ERROR PDU are described in sub-clause 
8C.3.4.3. 

8C.3.4.2 Sending of a RAN-INFORMATION-ERROR PDU 

A BSS receiving an erroneous RIM PDU according to sub-clause 8c. 3. 2 shall: 

1> set the PDU type IE, mirror the Source Cell Identifier IE value and the Destination Cell Identifier IE value of the 
erroneous RIM PDU respectively into the Destination Cell Identifier IE and the Source Cell Identifier IE of the 
RAN-INFORMATION-ERROR PDU 

1> set the content of RIM Container IE as follows: 

2> mirror the RIM Application Identity IE value of the erroneous RIM PDU into the RIM Application Identity IE 
in the RIM Container IE of the RAN-INFORMATION-ERROR PDU; 

2> set the RIM Cause IE and, if necessary, the RIM Protocol Version Number IE (see sub-clause 8c. 1 .6); 

2> include the complete erroneous RIM PDU in to the PDU in Error IE; 

1> send the RAN-INFORMATION-ERROR PDU. 

8C.3.4.3 Reception of a RAN-INFORMATION-ERROR PDU in the BSS 

Upon reception of an erroneous RAN-INFORMATION-ERROR PDU according to sub-clause 8c.3.2 the BSS shall 
discard the received PDU without further action. 
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The actions to be taken upon reception of a valid RAN-INFORMATION-ERROR PDU are an implementation- 
dependent option. 

8c.4 RIM timers 

The following RIM timers are defined: 

T(RIR) is used in the controlling BSS to control the reception of the response to a previously transmitted 

RAN-INFORMATION-REQUEST PDU. 

T(RI) is used in the serving BSS used to control the reception of the acknowledgement of a previously 

transmitted RAN-INFORMATION PDU. 

T(RIAE) is used in the controlling BSS used to control the reception of the acknowledgement of a 

previously transmitted RAN-INFORMATION- APPLICATION-ERROR PDU. 

Table 8c.4: RIM timers 



Timer 


Start 


Stop 


Action at expiry 


T(RIR) 


Transmission of a RAN- 
INFORMATION- 
REQUEST/Multiple Report PDU 


Reception of the answering RAN- 
INFORMATION/lnitial Multiple 
Report 


Either (implementation option) 
inform the application that the 
procedure has failed or restart the 
procedure a finite number of times 


Transmission of a RAN- 
INFORMATION-REQUEST/Single 
Report PDU 


Reception of the answering RAN- 
INFORMATION/Single Report 


Either (implementation option) 
inform the application that the 
procedure has failed or restart the 
procedure a finite number of times 


Transmission of a RAN- 

INFORIVIATION-REQUEST/Stop 

PDU 


Reception of the answering RAN- 
INFORMATION/Stop 


Either (implementation option) 
inform the application that the 
procedure has failed or restart the 
procedure a finite number of times 


T(RI) 


Transmission of a RAN- 
INFORMATION/Multiple Reporter 
RAN-INFORMATION/End PDU 


Reception of the answering RAN- 
INFORMATION-ACK 


Either (implementation option) 
inform the application that the 
procedure has failed or restart the 
procedure a finite number of times 


T(RIAE) 


Transmission of a RAN- 
INFORMATION-APPLICATION- 
ERROR PDU 


Reception of the answering RAN- 
INFORMATION-ACK 


Either (implementation option) 
inform the application that the 
procedure has failed or restart the 
procedure a finite number of times 



8c.5 Action upon deletion of a cell in a BSS 
8C.5.0 General 

The deletion of a cell in a BSS should trigger the actions described in this sub-clause to ensure the proper operation of 
the RIM procedures for RIM associations related to this cell. 

8C.5.1 Actions due to the deletion of the cell 

If the deleted cell has to report to one or more controlling BSS(s), the serving BSS parenting the deleted cell shall 
trigger a RAN Information Send procedure to inform each of the corresponding controlling BSS(s) that multiple 
reporting has been deactivated by the sending of a RAN-INFORMATION/End PDU. 

The controlling BSS parenting the deleted cell may also decide that, as a consequence of the deletion of this cell, some 
multiple reports previously requested from some cells parented by other BSS(s) are no longer needed and shall trigger 
the relevant RAN Information Request/Stop procedure. 
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8C.5.2 Additional actions in tine case the deleted cell is used as a source 
cell by RIM 

If the cell identifier of the cell being deleted has been used as the Source Cell Identifier IE value in a previous RAN- 
INFORMATION-REQUEST/Multiple report PDU, the deletion of this cell shall trigger the following additional actions 
to update this information in the serving BSS, as the Source Cell Identifier IE is used by the serving BSS to address the 
controlling BSS (address mirroring - see sub-clause 8c. 1.4.3): 

The controlling BSS parenting this cell shall trigger a RAN Information Request/Stop procedure for each of the 
involved cells in the serving BSS; 

After the completion of this procedure the parenting BSS shall, if event-based multiple reporting is still needed 
from the involved cells, trigger further RAN Information Request/Multiple Report procedure(s) with a different 
cell identifier as Source Cell Identifier IE value. 

8c.6 Specific requirements related to RIM applications 
8C.6.0 General requirements 

Any error condition detected in the Application Error Container IE included in the RIM Container IE of a valid RIM 
PDU shall not be reported to the peer application entity. 

Any error condition detected in the Application Container IE included in the RIM Container IE of an erroneous RIM 
PDU shall not trigger a RAN Information Application Error procedure. 

A controlling BSS shall not send another RAN-INFORMATION-REQUEST PDU for the same association before the 
first RAN-INFORMATION-REQUEST PDU has been acknowledged or before T(RIR) associated to this request has 
expired. 

8C.6.1 Requirements related to the NACC RIM application 

The rules specified in this sub-clause apply when the RIM Application Identity IE is set to "Network Assisted Cell 
Change (NACC)": 

- The RAN-INFORMATION-REQUEST PDU is used by a controlling BSS to request the system information 
required for NACC operation in the controlling BSS and related to a single cell parented by a serving BSS. The 
Destination Cell Identifier IE of the RAN-INFORMATION-REQUEST PDU shall be set to the value of the 
Reporting Cell Identifier field contained in the application container of the PDU. 

The presence of the Application Container IE is mandatory in the RIM Container IE of the RAN- 
INFORMATION-REQUEST PDU. 

- The RAN -INFORMATION PDU is used by a serving BSS to send the system information required for NACC 
operation (i.e. if a PBCCH is allocated in the cell, PSIl, a consistent set of PSI2 and PSI14 messages; if no 
PBCCH is allocated in the cell, SB, SI13 and, if available, SIl messages - see 3GPP TS 4.060) related to a 
single reporting cell, to a controlling BSS. 

In the present specification, NACC between UTRAN and GERAN is restricted to the case of a controlling RNS 
and a serving BSS (i.e. assistance is provided for MSs moving from UTRAN to GERAN) and NACC between 
E-UTRAN and GERAN is restricted to the case of a controlling eNodeB and a serving BSS (i.e. assistance is 
provided for MSs moving from E-UTRAN to GERAN). The reporting cell located in the serving BSS is 
therefore always a GERAN cell and shall be addressed as such (RAI + CI) in the NACC application containers. 

The presence of the Application Container IE is mandatory in the RIM Container IE of the RAN- 
INFORMATION PDU, except in the case of a RAN-INFORMATION/Initial Multiple Report PDU and of a 
RAN-INFORMATION/Single Report PDU, where the Application Error Container IE may be included instead. 

When multiple reports from a certain cell have been requested, the RAN-Information Send procedure shall be 
triggered every time the set of NACC related (packet) system information for this cell is changed; the NACC 
application shall request acknowledgements. 



£75/ 



3GPP TS 48.01 8 version 1 1 .3.0 Release 1 1 90 ETSI TS 1 48 01 8 V1 1 .3.0 (201 3-07) 

- The Application Container IE included in the RIM container IE of a RAN-INFORMATION/End PDU or of a 
RAN-INFORMATION/Stop PDU shall contain only the identity of the reporting cell. 

8C.6.2 SIS application 

The rules specified in this sub-clause apply when the RIM Application Identity IE is set to "SB": 

- the RAN-INFORMATION-REQUEST PDU is used by a controlling BSS to request system information type 
3 related to a single cell parented by a serving BSS. The Destination Cell Identifier IE of the RAN- 
INFORMATION-REQUEST PDU shall be set to the value of the Reporting Cell Identifier field contained in 
the application container of the PDU. 

The presence of the Application Container IE is mandatory in the RIM Container IE of the RAN- 
INFORMATION-REQUEST PDU. 

The RAN-INFORMATION PDU is used by a serving BSS to send system information type 3 related to a 
single reporting cell, to a controlling BSS. 

The presence of the Application Container IE is mandatory in the RIM Container IE of the RAN- 
INFORMATION PDU, except in the case of a RAN-INFORMATION/Initial Multiple Report PDU and of a 
RAN-INFORMATION/Single Report PDU, where the Application Error Container IE may be included 
instead. 

When multiple reports from a certain cell have been requested, the RAN-Information Send procedure shall be 
triggered every time the system information type 3 for this cell is changed; the SI3 application shall request 
acknowledgements . 

- The Application Container IE included in the RIM container IE of a RAN-INFORMATION/End PDU or of a 
RAN-INFORMATION/Stop PDU shall contain only the identity of the reporting cell. 

8C.6.3 MBMS data channel application 

The rules specified in this sub-clause apply when the RIM Application Identity IE is set to "MBMS data channel": 

- The RAN-INFORMATION-REQUEST PDU is used by a controlling BSS to request the information about the 
MBMS data channels established in a single cell controlled by a serving BSS. The Destination Cell Identifier IE 
of the RAN-INFORMATION-REQUEST PDU shall be set to the value of the Reporting Cell Identifier field 
contained in the application container of the PDU. 

The presence of the Application Container IE is mandatory in the RIM Container IE of the RAN- 
INFORMATION-REQUEST PDU. 

- The RAN-INFORMATION PDU is used by a serving BSS to send the information about the MBMS data 
channels established in a single reporting cell, to a controlling BSS. 

The presence of the Application Container IE is mandatory in the RIM Container IE of the RAN- 
INFORMATION PDU, except in the case of a RAN-INFORMATION/Initial Multiple Report PDU and of a 
RAN-INFORMATION/Single Report PDU, where the Application Error Container IE may be included instead. 

When multiple reports from a certain cell have been requested, the RAN-Information Send procedure shall be 
triggered every time the allocation of the MBMS data channel is changed (i.e. established, reconfigured, 
abnormally released) for any MBMS session ongoing in the reporting cell. The MBMS data channel application 
shall request acknowledgements. However the normal release (i.e. resulting from a MBMS-SESSION-STOP- 
REQUEST PDU received from the SGSN) of the MBMS data channel at the end of a session shall not trigger 
the RAN-Information Send procedure, but assumed implicitly as done at the end of the session by the the 
controlhng BSS. 

- The Application Container IE included in the RIM container IE of a RAN-INFORMATION/End PDU or of a 
RAN-INFORMATION/Stop PDU shall contain only the identity of the reporting cell. 
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8C.6.4 Requirements related to the SON Transfer RIM application 

The introduction of generic SON Transfer containers in TS 36.413 [36] means that the RIM procedure itself has to be 
understood in a more generic way for the SON Transfer RIM application: the RIM procedure triggered by the 
Controlling BSS is used to exchange between BSSs SON Transfer Request container (controlling — > serving) and 
SON Transfer Response container (serving — > controlling), the precise content of these containers (possibly NULL) 
being linked with the SON Transfer Application in use. The Reporting Cell Identifier may either identify a cell in the 
serving BSS or in the controlling BSS, depending on the value of the SON Transfer Application Identity as specified in 
TS 36.413 [36]. 

The rules specified in this sub-clause apply when the RIM Application Identity IE is set to "SON Transfer": 

- The RAN-INFORMATION-REQUEST PDU is used by a controlling BSS to send the SON Transfer Request 
container to the serving BSS as specified in TS 36.413 [36]. 

The procedure shall be triggered using single report or multiple reports. 

- The RAN-INFORMATION PDU is used by a serving BSS to send the SON Transfer Response Container to a 
controlhng BSS as specified in TS 36.413 [36]. 

The presence of the Application Container IE is mandatory in the RIM Container IE of the RAN- 
INFORMATION PDU, except in the case of a RAN-INFORMATION/Initial Multiple Report PDU and of a 
RAN-INFORMATION/Single Report PDU, where the Application Error Container IE may be included instead. 

When multiple reports have been requested, the RAN -Information Send procedure shall be triggered every time 
a SON Transfer Response Container must be sent. The RAN-Information Send procedure shall be used with 
lower priority with respect to the MS/UE dedicated signalling. 

8C.6.5 Requirements related to the UTRA SI RIM application 

The rules specified in this sub-clause apply when the RIM Application Identity IE is set to "UTRA System Information 
(UTRA SI)": 

- The RAN-INFORMATION-REQUEST PDU is used by a controlling BSS to request the UTRA system 
information in the controlling BSS and related to a cell parented by a serving BSS. 

The presence of the Application Container IE is mandatory in the RIM Container IE of the RAN- 
INFORMATION-REQUEST PDU. 

- The RAN-INFORMATION PDU is used by a serving BSS to send the UTRA system information related to a 
cell, to a controlling BSS. 

In the present specification, UTRA SI is transferred only to E-UTRAN. The reporting cell located in the serving 
BSS is always a cell and shall be addressed by the UTRAN Source Cell ID in the UTRA SI application 
containers. 

The presence of the Application Container IE is mandatory in the RIM Container IE of the RAN- 
INFORMATION PDU, except in the case of a RAN-INFORMATION/Initial Multiple Report PDU and of a 
RAN-INFORMATION/Single Report PDU, where the Application Error Container IE may be included instead. 

When multiple reports from a certain cell have been requested, the RAN-Information Send procedure shall be 
triggered every time the set of UTRA system information managed by the UTRA SI RIM application for this cell 
is changed; the UTRA SI application shall request acknowledgements. 

- The Application Container IE included in the RIM container IE of a RAN-INFORMATION/End PDU or of a 
RAN-INFORMATION/Stop PDU shall contain only the identity of the reporting cell. 
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8d Signalling procedures between MBMS SAPs 
8d.1 General 

Upon receiving an MBMS-SESSION-START-REQUEST PDU from the SGSN, if the BSS controls cells in any of the 
MBMS Service Areas in the MBMS service area list the BSS creates an MBMS Service Context, and acknowledges the 
SGSN using an MBMS-SESSION-START-RESPONSE PDU. More than one MBMS-SESSION-START-RESPONSE 
PDU can be sent from one BSS to the SGSN for the same MBMS-SESSION-START-REQUEST PDU. 

Upon receiving an MBMS-SESSION-UPDATE-REQUEST PDU from the SGSN, the BSS updates the MBMS service 
area list for the ongoing MBMS broadcast service session and acknowledges the SGSN using an MBMS-SESSION- 
UPDATE-RESPONSE PDU. More than one MBMS-SESSION-UPDATE-RESPONSE PDU can be sent from one BSS 
to the SGSN for the same MBMS-SESSION-UPDATE-REQUEST PDU. 

At the end of the MBMS Session the BSS receives an MBMS-SESSION-STOP-REQUEST PDU from the SGSN 
indicating that the MBMS Session can be released. The BSS acknowledges the request to end the MBMS Session by 
sending the MBMS-SESSION-STOP-RESPONSE PDU to the SGSN. See 3GPP TS 43.246 ([29]). 

8d.2 MBMS Session Start 

The BSS creates an MBMS Service Context if the BSS controls cells in the MBMS service area list upon reception of 
an MBMS-SESSION-START-REQUEST PDU from the SGSN. 

If the data is received by the BSS and no MBMS bearer is established on the radio interface for that MBMS Session the 
BSS may buffer the data. 

At reception of an MBMS-SESSION-START-REQUEST PDU that leads to an MBMS Service Context creation in the 
BSS, the BSS shall respond to the SGSN with an MBMS-SESSION-START-RESPONSE PDU with a Cause Value 
indicating that data transfer shall be initiated on the Point-to-Multipoint BVC from that SGSN. 

The SGSN may include the Allocation/Retention Priority information element in the MBMS-SESSION-START- 
REQUEST PDU. If this information element is received and the BSS supports ARP handling, the BSS shall 
establish or modify the resources according to the values of the Allocation/Retention Priority IE (priority level, 
pre-emption indicators) and the resource situation as follows: 

The BSS shall consider the priority level of the requested MBMS bearer, when deciding on the resource 
allocation. 

The priority levels and the pre-emption indicators may (singularly or in combination) be used to determine 
whether the MBMS bearer establishment has to be performed unconditionally and immediately. If the requested 
MBMS bearer is marked as "may trigger pre-emption" and the resource situation requires so, the BSS may 
trigger the pre-emption procedure which may then cause the forced release of a lower priority bearer which is 
marked as "pre-emptable". Whilst the process and the extent of the pre-emption procedure is operator-dependent, 
the pre-emption indicators, if given in the MBMS-SESSION-START-REQUEST PDU, shall be treated as 
follows: 

1. If the Pre-emption Capability IE is set to "may trigger pre-emption", then this allocation request may trigger 
the pre-emption procedure. The BSS shall only pre-empt bearers (other MBMS bearers or MS specific 
bearers) with lower priority, in ascending order of priority. 

2. If the Pre-emption Capability IE is set to "shall not trigger pre-emption", then this allocation request shall not 
trigger the pre-emption procedure. 

3. If the Pre-emption Vulnerability IE is set to "pre-emptable", then this connection shall be included in the pre- 
emption process. 

4. If the Pre-emption Vulnerability IE is set to "not pre-emptable", then this connection shall not be included in 
the pre-emption process. 



£75/ 



3GPP TS 48.01 8 version 1 1 .3.0 Release 1 1 



93 



ETSI TS 148 018 V1 1.3.0 (2013-07) 



5. If the Priority Level IE is set to "no priority" the given values for the Pre-emption Capability IE and Pre- 
emption Vulnerability IE shall not be considered. Instead the values "shall not trigger pre-emption" and "not 
pre-emptable" shall prevail. 

- If the Allocation/Retention Priority IE is not given in the MBMS-SESSION-START-REQUEST PDU, the 
allocation request shall not trigger the pre-emption process and the connection may be pre-empted and 
considered to have the value "lowest" as priority level. 

- The SGSN shall not include, and the BSS shall ignore, any queuing allowed indication in the 
Allocation/Retention Priority IE of the MBMS-SESSION-START-REQUEST PDU. 

The MBMS Session Repetition Number IE shall be included in the MBMS-SESSION-START-REQUEST PDU in case 
the MBMS Session Identity IE is included in the same PDU (and vice versa). The MBMS Session Repetition Number IE 
allows the BSS to recognize retransmissions of a specific session of an MBMS bearer service. The value part of this IE 
may be used for e.g. deciding whether or not to initiate the counting procedure on a per cell basis (see 3GPP TS 44.018, 
3GPP TS 44.060) or, in conjunction with the values of Allocation/Retention Priority IE, whether or not to establish an 
MBMS radio bearer for the session on a per cell basis. 

At reception of an MBMS-SESSION-START-REQUEST PDU with the same TMGI IE and MBMS Session Identity IE 
as an ongoing MBMS Service Context, the BSS shall respond to the SGSN with an MBMS-SESSION-START- 
RESPONSE PDU with a Cause Value indicating that data transfer has already been initiated on the Point-to-Multipoint 
BVC from another SGSN. 

At reception of an MBMS-SESSION-START-RESPONSE PDU, the SGSN shall either start data transfer or not 
depending on the received Cause Value. 

After transmission of the MBMS-SESSION-START-RESPONSE PDU, the BSS shall wait at least the time specified in 
the value part of the Time to MBMS Data Transfer IE included in the MBMS-SESSION-START-REQUEST PDU and 
at most a time exceeding by 5 seconds the value part of the Time to MBMS Data Transfer IE for the first reception of 
the associated data before the BSS validates whether or not there is another SGSN that previously has sent an MBMS- 
SESSION-START-REQUEST PDU. 

If after the start of the data flow associated to an MBMS Service Context, the BSS does not receive data for at least 30 
seconds and the BSS has not received the MBMS-SESSION-STOP-REQUEST PDU, the BSS vaHdates whether or not 
there is another SGSN that previously has sent an MBMS-SESSION-START-REQUEST PDU. 

If, in any of the two cases mentioned above, another SGSN has sent an MBMS-SESSION-START-REQUEST PDU, 
the BSS shall send an MBMS-SESSION-START-RESPONSE PDU to such an SGSN with a Cause Value indicating 
that data transfer shall be initiated on the Point-to-Multipoint BVC from that SGSN. Otherwise, the BSS shall end the 
MBMS Service Context. 

In any case, the BSS will send an MBMS-SESSION-START-RESPONSE PDU with a Cause Value indicating that the 
MBMS Service Context has been released due to interrupted data flow to the SGSN that previously has been ordered to 
perform data transfer. 

If the BSS does not support any MBMS Service Area in the MBMS Service Area Identity List the BSS will send an 
MBMS-SESSION-START-RESPONSE PDU to the SGSN with Cause Value indicating that none of the listed MBMS 
Service Areas are supported by the BSS. 



SGSN 



BSS 



MBMS-SESSION-START-REQUEST 



MBMS-SESSION-START-RESPONSE 



MBMS-SESSION-START-RESPONSE 



Figure 8d.2: MBMS Session Start procedure 
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8d.2.1 Abnormal Conditions 

In any failure case in BSS the BSS may send an MBMS-SESSION-START-RESPONSE PDU including a Cause Value 
indicating the reason for the failure. 

If an MBMS-SESSION-START-RESPONSE PDU is not received in response to an MBMS-SESSION-START- 
REQUEST PDU within Tl 1 seconds, then the MBMS-SESSION-START-REQUEST PDU shall be repeated a 
maximum of MBMS-SESSION-START-REQUEST-RETRIES attempts. After MBMS-SESSION-START-REQUEST- 
RETRIES + 1 attempts the procedure is stopped and the O&M is informed. 



8d.3 MBMS Session Stop 



The SGSN may terminate an MBMS Session in the BSS by sending the MBMS-SESSION-STOP -REQUEST PDU to 
the BSS. The SGSN shall include the MBMS Stop Cause IE in the MBMS-SESSION-STOP-REQUEST PDU to 
indicate to the BSS if the MBMS Session termination has been ordered by an upstream node or if the SGSN itself has 
decided to terminate the MBMS Session (due to e.g. that the last MS that has an active MBMS UE Context for the 
MBMS Session within the SGSN has left the routing area(s) handled by the BSS). 

The BSS ends an MBMS Service Context upon reception of an MBMS-SESSION-STOP-REQUEST PDU, including 
the MBMS Stop Cause IE indicating that an upstream node is terminating the MBMS Session, from the SGSN and 
acknowledges with an MBMS-SESSION-STOP-RESPONSE PDU. 

At reception of an MBMS-SESSION-STOP-REQUEST PDU including the MBMS Stop Cause IE indicating that the 
SGSN is terminating the MBMS Session, the BSS shall validate whether or not there is another SGSN that previously 
has sent an MBMS-SESSION-START-REQUEST PDU or, in case of an MBMS broadcast service session, an MBMS- 
SESSION-UPDATE-REQUEST PDU. 

If another SGSN has sent an MBMS-SESSION-START-REQUEST PDU or an MBMS-SESSION-UPDATE- 
REQUEST PDU, the BSS shall send an MBMS-SESSION-START-RESPONSE PDU or an MBMS-SESSION- 
UPDATE-RESPONSE PDU, respectively, to such an SGSN with a Cause Value indicating that data transfer shall be 
initiated on the Point-to-Multipoint BVC from that SGSN. Otherwise, the BSS shall end the MBMS Service Context. 
The BSS shall then acknowledge the MBMS-SESSION-STOP-REQUEST PDU by sending an MBMS-SESSION- 
STOP-RESPONSE PDU to the SGSN. 



SGSN 



BSS 



MBMS-SESSION-STOP-REQUEST 

H 



MBMS-SESSION-STOP-RESPONSE 

M 



Figure 8d.3: MBMS Session Stop procedure 

8d.3.1 Abnormal Conditions 

If an MBMS-SESSION-STOP-RESPONSE PDU is not received in response to an MBMS-SESSION-STOP- 
REQUEST PDU within Tl 1 seconds, then the MBMS-SESSION-STOP-REQUEST PDU shall be repeated a maximum 
of MBMS-SESSION-STOP-REQUEST-RETRIES attempts. After MBMS-SESSION-STOP-REQUEST-RETRIES + 1 
attempts the procedure is stopped and the O&M is informed. 



8d.4 MBMS Session Update 



Upon reception of an MBMS-SESSION-UPDATE-REQUEST PDU from the SGSN for an ongoing MBMS broadcast 
service session, the BSS creates an MBMS Service Context if the BSS controls cells in the MBMS service area list and 
there is no ongoing MBMS Service Context identified with the same TMGI IE and, if available, MBMS Session Identity 
IE in the BSS. 
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Upon reception of an MBMS-SESSION-UPDATE-REQUEST PDU with the same TMGI IE and, if available, MBMS 
Session Identity IE as an ongoing MBMS Service Context but with (a) new MBMS Service Area(s) added to the MBMS 
Service Area Identity List IE, the BSS may send assignments for the ongoing MBMS broadcast service session to the 
mobile stations in the new MBMS Service Area(s) and repeat notifications to the mobile stations in the old MBMS 
Service Area(s). 

Upon reception of an MBMS-SESSION-UPDATE-REQUEST PDU with the same TMGI IE and, if available, MBMS 
Session Identity IE as an ongoing MBMS Service Context but without (an) old MBMS Service Area(s) included any 
longer in the MBMS Service Area Identity List IE, the BSS shall release MBMS radio bearers relevant to the ongoing 
MBMS broadcast service session in the old MBMS Service Area(s). 

The MBMS Session Information IE shall denote a Broadcast MBMS Session. 

The Allocation/Retention Priority IE, if available, and the MBMS Session Repetition Number IE, if available, shall be 
handled by the BSS as described in the MBMS Session Start procedure (see sub-clause 8d.2). 

If the Allocation/Retention Priority IE is not present in the MBMS-SESSION-UPDATE-REQUEST PDU, the 
allocation request shall not trigger the pre-emption process and the connection may be pre-empted and considered to 
have the value "lowest" as priority level. 

If the data is received by the BSS and no MBMS bearer is established on the radio interface for that MBMS Session, the 
BSS may buffer the data. 

At reception of an MBMS-SESSION-UPDATE-REQUEST PDU that leads to an MBMS Service Context creation in 
the BSS, the BSS shall respond to the SGSN with an MBMS-SESSION-UPDATE-RESPONSE PDU with a Cause 
Value indicating that data transfer shall be initiated on the Point-to-Multipoint BVC from that SGSN. 

At reception of an MBMS-SESSION-UPDATE-REQUEST PDU with the same TMGI IE and, if available, MBMS 
Session Identity IE as an ongoing MBMS Service Context and including new and/or removing old MBMS Service 
Area(s), the BSS shall respond to the SGSN with an MBMS-SESSION-UPDATE-RESPONSE PDU with a Cause 
Value indicating either that data transfer shall continue on the Point-to-Multipoint BVC from that SGSN (see note) or 
that data transfer has already been initiated on the Point-to-Multipoint BVC from another SGSN. 

NOTE: The Cause Value indicating that data transfer shall continue on the Point-to-Multipoint BVC from that 

SGSN is set to the same one denoting that data transfer shall be initiated on the Point-to-Multipoint BVC 
from that SGSN, i.e. "0001" (see sub-clause 11.3.74). 

If the BSS does not support any MBMS Service Area in the MBMS Service Area Identity List IE, the BSS shall send an 
MBMS-SESSION-UPDATE-RESPONSE PDU to the SGSN with a Cause Value indicating that none of the listed 
MBMS Service Areas are supported by the BSS. 

At reception of an MBMS-SESSION-UPDATE-RESPONSE PDU, the SGSN shall either start/continue data transfer or 
not depending on the received Cause Value. 

After transmission of the MBMS-SESSION-UPDATE-RESPONSE PDU, the BSS shall wait at least the time specified 
in the value part of the Time to MBMS Data Transfer IE included in the MBMS-SESSION-UPDATE-REQUEST PDU 
and at most a time exceeding by 5 seconds the value part of the Time to MBMS Data Transfer IE for the first reception 
of the associated data before the BSS validates whether or not there is another SGSN that previously has sent an 
MBMS-SESSION-UPDATE-REQUEST PDU or an MBMS-SESSION-START-REQUEST PDU with the same 
content of the received MBMS-SESSION-UPDATE-REQUEST PDU. 

If after the start of the data flow associated to an MBMS Service Context, the BSS does not receive data for at least 30 
seconds and the BSS has not received the MBMS-SESSION-STOP-REQUEST PDU, the BSS vaHdates whether or not 
there is another SGSN that previously has sent an MBMS-SESSION-UPDATE-REQUEST PDU or an MBMS- 
SESSION-START-REQUEST PDU with the same content of the received MBMS-SESSION-UPDATE-REQUEST 
PDU. 

If, in any of the two cases mentioned above, another SGSN has sent an MBMS-SESSION-UPDATE-REQUEST PDU 
or an MBMS-SESSION-START-REQUEST PDU, the BSS shall send an MBMS-SESSION-UPDATE-RESPONSE 
PDU or an MBMS-SESSION-START-RESPONSE PDU, respectively, to such an SGSN with a Cause Value indicating 
that data transfer shall be initiated on the Point-to-Multipoint BVC from that SGSN. Otherwise, the BSS shall end the 
MBMS Service Context. 
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In any case, the BSS shall send an MBMS-SESSION-UPDATE-RESPONSE PDU with a Cause Value indicating that 
the MBMS Service Context has been released due to interrupted data flow to the SGSN that previously has been 
ordered to perform data transfer. 



SGSN 



BSS 



MBMS-SESSION-UPDATE-REQUEST 



MBMS-SESSION-UPDATE-RESPONSE 



MBMS-SESSION-UPDATE-RESPONSE 



Figure 8d.4: MBMS Session Update procedure 

8d.4.1 Abnormal Conditions 

In any failure case in BSS the BSS may send an MBMS-SESSION-UPDATE-RESPONSE PDU including a Cause 
Value indicating the reason for the failure. 

If an MBMS-SESSION-UPDATE-RESPONSE PDU is not received in response to an MBMS-SESSION-UPDATE- 
REQUEST PDU within Tl 1 seconds, then the MBMS-SESSION-UPDATE-REQUEST PDU shall be repeated a 
maximum of MBMS-SESSION-UPDATE-REQUEST-RETRIES attempts. After MBMS-SESSION-UPDATE- 
REQUEST-RETRIES -i- 1 attempts the procedure is stopped and the O&M is informed. 



9 General Protocol Error Handling 

Refer to General Protocol Error Handling/3GPP TS 48.016. In addition: 

any type of BSSGP PDU received without an expected conditional IE is discarded and a STATUS PDU (cause 
"Missing conditional IE") is sent; 

any type of BSSGP PDU received without a mandatory IE is discarded and a STATUS PDU (cause "Missing 
mandatory IE") is sent; 

any type of BSSGP PDU received with a syntactical error in an expected conditional IE is discarded and a 
STATUS PDU (cause "Conditional IE error") is sent; 

any type of BSSGP PDU received with a syntactical error in a mandatory IE is discarded and a STATUS PDU 
(cause "Invalid mandatory information") is sent; 

any type of BSSGP PDU received for a feature that is not negotiated is discarded and a STATUS PDU (cause 
"PDU not compatible with the feature set") is sent. 

Some BSSGP PDU shall contain one and only one conditional IE amongst a defined list of possible conditional IE 
(e.g. PAGING-PS PDU). If such a BSSGP PDU is received with more than one conditional IE amongst the defined list 
of possible conditional IE, as defined in sub-clause 10, the PDU is discarded and a STATUS PDU (cause "Unexpected 
conditional IE") is sent. 



10 



PDU functional definitions and contents 



10.1 General Structure Of A PDU 

Refer to General Structure Of A PDU/3GPP TS 48.016 [16]. 
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1 0.2 PDU functional definitions and contents at RL and BSSGP 
SAPs 

10.2.1 DL-UNITDATA 

This PDU is sent to the BSS to transfer an LLC-PDU across the radio interface to an MS. 
PDU type: DL-UNITDATA 

Direction: SGSN to BSS 

Table 10.2.1 : DL-UNITDATA PDU contents 



Information element 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI (current) 


TLLI/1 1.3.35 


M 


V 


4 


QoS Profile (note 1) 


OoS Profile/1 1.3.28 


M 


V 


3 


PDU Lifetime 


PDU Lifetime/1 1.3.25 


M 


TLV 


4 


IVIS Radio Access Capability (note 
2) 


IVIS Radio Access Capability/1 1 .3.22 





TLV 


7-? 


Priority (note 3) 


Priority/11.3.27 





TLV 


3 


DRX Parameters 


DRX Parameters/1 1.3.11 





TLV 


4 


IMSI 


IMSI/11.3.14 





TLV 


5-10 


TLLI (old) 


TLLI/1 1.3.35 





TLV 


6 


PFI 


PFI/1 1.3.42 





TLV 


3 


LSA Information 


LSA Information/1 1.3.19 





TLV 


7-? 


Service UTRAN CCO 


Service UTRAN CCO/1 1 .3.47 





TLV 


3 


Subscriber Profile ID for 
RAT/Frequency priority (note 5) 


Subscriber Profile ID for 
RAT/Frequency priority/1 1 .3.105 





TLV 


3 


Redirection Indication (note 6) 


Redirection Indication/11.3.112 





TLV 


3 


Redirection Completed (note 7) 


Redirection Completed/1 1.3.113 





TLV 


3 


Unconfirmed send state variable 
(note 9) 


Unconfirmed send state 
variable/11.3.114 


c 


TLV 


4 


SCI (note 10) 


SCI/11.3.116 





TLV 


3 


GGSN/P-GW location (note 10) 


GGSN/P-GW location/1 1.3.117 





TLV 


3 


Alignment octets 


Alignment octets/1 1 .3.1 





TLV 


2-5 


LLC-PDU (note 4) 


LLC-PDU/1 1.3.15 


M 


TLV 


2-? 


Initial LLC-PDU (note 8) 


LLC-PDU/1 1.3.15 





TLV 


2-? 


NOTE 1 : Some attributes of the QoS Profile shall be discarded if the PFI field is present and corresponds to a 

known PFC in the BSS. 
NOTE 2: The field shall be present if there is valid MS Radio Access Capability information known by the 

SGSN; the field shall not be present otherwise. 
NOTE 3: The priority field shall be discarded if the PFI field is present and corresponds to a known PFC in the 

BSS for which the ARP field was received. 
NOTE 4: The LLC-PDU Length Indicator may be zero. 
NOTE 5: This IE may be included if available in the SGSN. If the Service UTRAN CCO IE is present with the 

value of "shall not" the Service UTRAN CCO IE takes precedence over this IE. 
NOTE 6: This IE shall be included if Redirect Attempt flag was present in UL-UNITDATA and the CN requests 

rerouting by the BSC to another CN operator. 
NOTE 7: This IE shall be included if Redirect Attempt flag was present in UL-UNITDATA and the redirection is 

completed. 
NOTE 8: The initial Layer 3 Information received from IVIS. Only present when Redirection Indication is 

present. 
NOTE 9: Contains the value of the V(U) as defined in 3GPP TS 44.064 [12] if Redirection Indication IE is 

present. 
NOTE 10: These lEs are included when the SGSN supports the SIRUG feature and the received GTP-U packet 

contained the SCI IE. 



10.2.2 UL-UNITDATA 

This PDU transfers an MS's LLC-PDU and its associated radio interface information across the Gb-interface. 
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PDU type: 
Direction: 



UL-UNITDATA 
BSS to SGSN 



Table 10.2.2: UL-UNITDATA PDU content 



Information element 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


V 


4 


QoS Profile 


QoS Profile/1 1 .3.28 


M 


V 


3 


Cell Identifier 
(note 5) 


Cell Identifier/11.3.9 


M 


TLV 


10 


PFI 


PFI/1 1.3.42 





TLV 


3 


LSA Identifier List 


LSA Identifier List/1 1.3.18 





TLV 


3-? 


Redirect Attempt Flag 
(Note 3) 


Redirect Attempt 
Flag/11.3.111 





TLV 


3 


IMS! (note 2) 


IMSI/1 1.3.14 





TLV 


5-10 


Unconfirmed send 
state variable (note 4) 


Unconfirmed send state 
variable/11.3.114 





TLV 


4 


Selected PLMN ID 
(note 5) 


Selected PLMN 
ID/11.3.118 





TLV 


5 


Alignment octets 


Alignment octets/1 1.3.1 





TLV 


2-5 


LLC-PDU(notel) 


LLC-PDU/11.3.15 


M 


TLV 


2-? 


NOTE 1 : The LLC-PDU Length Indicator may be zero. 

NOTE 2: IMSI shall be included if available and if Redirect Attempt Flag is present. 

NOTE 3: This element indicates that the core network shall respond with either 

Redirection Indication IE or Redirection Completed IE in DL_UNITDATA 
NOTE 4: Unconfirmed send state variable shall be included if received in the previous 

DL_UNITDATA. 
NOTE 5: Selected PLIVIN ID shall be included in the case of a mobile station 

supporting network sharing when a foreign TLLI or a random TLLI is 

included in the UL-UNIDATA PDU; in such a case the Common PLMN ID 

shall be included within the Cell Identifier IE 



10.2.3 RA-CAPABILITY 

This PDU informs the BSS of the new Radio Access CapabiHty of an MS. 
PDU type: RA-CAPABILITY 

Direction: SGSN to BSS 

Table 10.2.3: RA-CAPABILITY PDU content 



Information element 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


MS Radio Access Capability 


MS Radio Access Capability/1 1 .3.22 


M 


TLV 


7-? 
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10.2.4 (void) 



1 0.2.5 DL-MBMS-UNITDATA 

This PDU is sent to the BSS to transfer an LLC-PDU across the radio interface. 
PDU type: DL-MBMS-UNITDATA 

Direction: SGSN to BSS 

Table 10.2.5: DL-MBMS-UNITDATA PDU contents 



Information element 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/11 .3.26 


M 


V 


1 


PDU Lifetime 


PDU Lifetime/1 1 .3.25 


M 


TLV 


4 


TMGI 


TMGI/ 11.3.77 


M 


TLV 


3-8 


IVIBIVIS Session Identity 


MBMS Session Identity/ 1 1 .3.71 





TLV 


3 


Alignment octets 


Alignment octets/11 .3.1 





TLV 


2-5 


LLC-PDU 


LLC-PDU/1 1.3.15 


M 


TLV 


3-? 



10.2.6 UL-MBMS-UNITDATA 

This PDU transfers an LLC-PDU for an MBMS session across the Gb-interface. 
PDU type: UL-MBMS-UNITDATA 

Direction: BSS to SGSN 

Table 10.2.6: UL-MBMS-UNITDATA PDU contents 



Information element 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TMGI 


TMGI/ 11.3.77 


M 


TLV 


3-8 


MBMS Session Identity 


MBMS Session Identity/ 1 1 .3.71 





TLV 


3 


Alignment octets 


Alignment octets/1 1 .3.1 





TLV 


2-5 


LLC-PDU (notel) 


LLC-PDU/1 1.3.15 


M 


TLV 


2-? 


NOTE: The LLC-PDU Length Indicator shall be zero in this version of the specifications. 



1 0.3 PDU functional definitions and contents at GMM SAP 
10.3.1 PAGING PS 

This PDU indicates that a BSS shall initiate the packet paging procedure for an MS within a group of cells. 
PDU type: PAGING-PS 

Direction: SGSN to BSS 

Table 10.3.1: PAGING PS PDU content 



Information elements Type / Reference Presence Format Length 
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PDU type 


PDU type/11 .3.26 


M 


V 


1 


IMSI 


IMSI/11.3.14 


M 


TLV 


5-10 


DRX Parameters 


DRX Parameters/1 1.3.11 





TLV 


4 


BVCI (note) 


BVCI/1 1.3.6 


C 


TLV 


4 


Location Area (note) 


Location Area/11.3.17 


C 


TLV 


7 


Routeing Area (note) 


Routeing Area/11.3.31 


C 


TLV 


8 


BSS Area Indication (note) 


BSS Area Indication/1 1 .3.3 


C 


TLV 


3 


PFI 


PFI/1 1.3.42 





TLV 


3 


ABQP 


ABOP/1 1.3.43 





TLV 


13-? 


QoS Profile 


OoS Profile/1 1.3.28 


M 


TLV 


5 


P-TMSI 


TMSI/1 1.3.36 





TLV 


6 


NOTE: One and only one of the conditional lEs shall be present. No repeated instances of 
the conditional IBs are permissible (e.g. one and only one Location Area shall be 
present). 



10.3.2 PAGING CS 

This PDU indicates that a BSS shall initiate a circuit-switched paging procedure for an MS within a group of cells. 
PDU type: PAGING-CS 

Direction: SGSN to BSS 

Table 10.3.2: PAGING CS PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


IMSI 


IMSI/11.3.14 


M 


TLV 


5-10 


DRX Parameters 


DRX Parameters/11.3.11 


M 


TLV 


4 


BVCI (note 1) 


BVCI/1 1.3.6 


C 


TLV 


4 


Location Area (note 1 ) 


Location Area/11.3.17 


C 


TLV 


7 


Routeing Area (note 1) 


Routeing Area/11.3.31 


C 


TLV 


8 


BSS Area Indication (note 1) 


BSS Area Indication/1 1.3.3 


C 


TLV 


3 


TLLI 


TLLI/1 1.3.35 





TLV 


6 


Channel needed (note 2) 


Channel needed/11.3.10 





TLV 


3 


elVILPP-Priority (note 2) 


eMLPP-Priority/1 1.3.12 





TLV 


3 


TMSI (note 2) 


TMSI/1 1.3.36 





TLV 


6 


Global CN-ld (note 2) 


Global CN-ld/1 1.3.69 





TLV 


7 


NOTE 1 : One and only one of the conditional IBs shall be present. No repeated instances of 
the conditional IBs are permissible (e.g. one and only one Location Area shall be 
present). 

NOTE 2: These fields are provided by the IVISC via the Gs-lnterface. 



1 0.3.3 RA-CAPABILITY-UPDATE 

This PDU requests that the SGSN send an MS's current Radio Access capability or IMSI to the BSS. 
PDU type: RA-CAPABILITY-UPDATE 

Direction: BSS to SGSN 

Table 10.3.3: RA-CAPABILITY-UPDATE PDU content 



Information element 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/1 1.3.35 


M 


TLV 


6 


Tag 


Tag/11.3.34 


M 


TLV 


3 
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1 0.3.4 RA-CAPABILITY-UPDATE-ACK 

This PDU provides the BSS with an MS's current Radio Access capability and IMSI. 
PDU type: RA-CAPABILITY-UPDATE-ACK 

Direction: SGSN to BSS 

Table 10.3.4: RA-CAPABILITY-UPDATE-ACK PDU content 



Information element 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


Tag 


Tag/1 1 .3.34 


M 


TLV 


3 


IMSI (note) 


IMSI/11.3.14 


C 


TLV 


5-10 


RA-Cap-UPD-CAUSE 


RA-Cap-UPD- 
CAUSE/1 1.3.30 


M 


TLV 


3 


MS Radio Access Capability 


MS Radio Access 
Capability/1 1 .3.22 


C 


TLV 


7-? 


NOTE: If RA-Cap-UPD-CAUSE is not set to "OK", then neither the MS Radio Access 
Capability nor the IMSI shall be present. Otherwise, the IMSI shall be present. 



10.3.5 RADIO-STATUS 

This PDU indicates that an exception condition related to the radio interface has occurred. 
PDU type: RADIO-STATUS 

Direction: BSS to SGSN 

Table 10.3.5: RADIO-STATUS PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1 .3.26 


M 


V 


1 


TLLI (note) 


TLLI/11.3.35 


C 


TLV 


6 


TMSI (note) 


TMSI/1 1.3.36 


C 


TLV 


6 


IMSI (note) 


IMSI/11.3.14 


c 


TLV 


5-10 


Radio Cause 


Radio Cause/11.3.29 


M 


TLV 


3 


NOTE: One and only one of the conditional lEs shall be present. 



10.3.6 SUSPEND 

This PDU indicates that an MS wishes to suspend its GPRS service. 
PDU type: SUSPEND 

Direction: BSS to SGSN 

Table 10.3.6: SUSPEND PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


Routeing Area 


Routeing Area/11.3.31 


M 


TLV 


8 
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10.3.7 SUSPEND-ACK 

This PDU positively acknowledges the reception of a SUSPEND PDU for an MS. 
PDU type: SUSPEND-ACK 

Direction: SGSN to BSS 

Table 10.3.7: SUSPEND-ACK PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


Routeing Area 


Routeing Area/11.3.31 


M 


TLV 


8 


Suspend Reference Number 


Suspend Reference Number/11.3.33 


M 


TLV 


3 



10.3.8 SUSPEND-NACK 

This PDU negatively acknowledges the reception of a SUSPEND PDU for an MS. 
PDU type: SUSPEND-NACK 

Direction: SGSN to BSS 

Table 10.3.8: SUSPEND-NACK PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1 .3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


Routeing Area 


Routeing Area/11.3.31 


M 


TLV 


8 


Cause 


Cause/11.3.8 





TLV 


3 



10.3.9 RESUME 

This PDU indicates that an MS wishes to RESUME its GPRS service. 
PDU type: RESUME 

Direction: BSS to SGSN 

Table 10.3.9: RESUME PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


Routeing Area 


Routeing Area/11.3.31 


M 


TLV 


8 


Suspend Reference Number 


Suspend Reference Number/11.3.33 


M 


TLV 


3 



£75/ 



3GPP TS 48.01 8 version 1 1 .3.0 Release 1 1 



103 



ETSI TS 148 018 V1 1.3.0 (2013-07) 



10.3.10 RESUME-ACK 

This PDU positively acknowledges the reception of a RESUME PDU for an MS. 
PDU type: RESUME-ACK 

Direction: SGSN to BSS 

Table 10.3.10: RESUME-ACK PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1 .3.26 


M 


V 


1 


TLLI 


TLLI/1 1.3.35 


M 


TLV 


6 


Routeing Area 


Routeing Area/11.3.31 


M 


TLV 


8 



10.3.11 RESUME-NACK 

This PDU negatively acknowledges the reception of a RESUME PDU for an MS. 



PDU type: 
Direction: 



RESUME-NACK 
SGSN to BSS 

Table 10.3.11: RESUME-NACK PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/1 1.3.35 


M 


TLV 


6 


Routeing Area 


Routeing Area/11.3.31 


M 


TLV 


8 


Cause 


Cause/11.3.8 





TLV 


3 



1 0.4 PDU functional definitions and contents at NIVI SAP 
10.4.1 FLUSH-LL 

This PDU informs a BSS that an MS has moved from one cell to another. 
PDU type: FLUSH-LL 

Direction: SGSN to BSS 

Table 10.4.1: FLUSH-LL PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1 .3.26 


M 


V 


1 


TLLI 


TLLI/1 1.3.35 


M 


TLV 


6 


BVCI (old) 


BVCI/1 1.3.6 


M 


TLV 


4 


BVCI (new) 


BVCI/1 1.3.6 





TLV 


4 


NSEI (new) 


NSEI/1 1.3.48 


(note) 


TLV 


4 


NOTE: NSEI (new) is included if the SGSN supports "Inter-NSE re-routing" or "LCS 
Procedures" and the old NSE supports the "Inter-NSE re-routing" or "LCS 
Procedures" and the cell change is an Inter-NSE cell change within a routing 
area. 
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10.4.2 FLUSH-LL-ACK 

This PDU indicates that LLC-PDU(s) buffered for an MS in the old cell have been either deleted or transferred to the 
new cell within the routing area. 



PDU type: 
Direction: 



FLUSH-LL-ACK 
BSS to SGSN 



Table 10.4.2: FLUSH-LL-ACK PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


Flush Action 


Flush Action/11.3.13 


M 


TLV 


3 


BVCI (new) 


BVCI/11.3.13 


C (note 1 ) 


TLV 


4 


Number of octets affected 


Number of octets affected/1 1 .3.41 


M 


TLV 


5 


NSEI (new) 


NSEI/11.3.48 


C (note 2) 


TLV 


4 


NOTE 1 : BVCI (new) is included only if Flush action indicated that LLC-PDUs are transferred. 
NOTE 2: NSEI (new) is included only if BVCI(new) is included and NSEI (new) is received in the 
FLUSH-LL PDU. 



10.4.3 LLC-DISCARDED 

This PDU indicates that a number of buffered LLC-PDUs in a cell for an MS have been deleted inside the BSS (because 
of PDU Lifetime expiration or radio outage for example). The LLC frames and the related octets deleted by the BSS as 
a consequence of a FLUSH-LL procedure (see sub-clause 8.1) shall not be reported a second time by means of an LLC- 
DISCARDED PDU. 



PDU type: 
Direction: 



LLC-DISCARDED 
BSS to SGSN 



Table 10.4.3: LLC-DISCARDED PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


LLC Frames Discarded 


LLC Frames Discarded/11.3.16 


M 


TLV 


3 


BVCI 


BVCI/1 1.3.6 


M 


TLV 


4 


Number of octets deleted 


Number of octets affected/1 1 .3.41 


M 


TLV 


5 


PFI (note) 


PFI/1 1.3.42 





TLV 


3 


NOTE: The PFI may be provided in case the PFC flow control feature is negotiated. It 

corresponds to the Packet Flow Identifier of the PFC for which LLC frames have been 
discarded. 
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1 0.4.4 FLOW-CONTROL-BVC 

This PDU informs the flow control mechanism at an SGSN of the status of a BVC's maximum acceptable SGSN to BSS 
throughput on the Gb interface. 



PDU type: 
Direction: 



FLOW-CONTROL-BVC 
BSS to SGSN 



Table 10.4.4: FLOW-CONTROL-BVC PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/11 .3.26 


M 


V 


1 


Tag 


Tag/1 1 .3.34 


M 


TLV 


3 


BVC Bucket Size 


BVC Bucket Size/1 1 .3.5 


M 


TLV 


4 


Bucket Leak Rate 


Bucket Leak Rate/1 1 .3.4 


M 


TLV 


4 


Bmax default MS 


Bmax default MS/1 1 .3.2 


M 


TLV 


4 


R default MS 


R default MS/11.3.32 


M 


TLV 


4 


Bucket Full Ratio 


Bucket Full Ratio/1 1 .3.46 


C 


TLV 


3 


BVC Measurement 


BVC Measurement/1 1 .3.7 





TLV 


4 


Flow Control 
Granularity (note) 


Flow Control 
Granularity/11.3.102 





TLV 


3 


NOTE: The Flow Control Granularity shall be provided in case the Gigabit Interface 
feature is negotiated. 



1 0.4.5 FLOW-CONTROL-BVC-ACK 

This PDU informs the flow control mechanism at the BSS that the SGSN has received the FLOW-CONTROL-BVC 
PDU indicated by the Tag. 



PDU type: 
Direction: 



FLOW-CONTROL-BVC-ACK 
SGSN to BSS 

Table 10.4.5: FLOW-CONTROL-BVC-ACK PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


Tag 


Tag/1 1 .3.34 


M 


TLV 


3 



1 0.4.6 FLOW-CONTROL-MS 

This PDU informs the flow control mechanism at an SGSN of the status of an MS's maximum acceptable SGSN to BSS 
throughput on the Gb interface. 

PDU type: FLOW-CONTROL-MS 

Direction: BSS to SGSN 

Table 10.4.6: FLOW-CONTROL-MS PDU content 



Information elements Type / Reference Presence Format Length 
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PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


Tag 


Tag/1 1 .3.34 


M 


TLV 


3 


MS Bucket Size 


MS Bucket Size/1 1.3.21 


M 


TLV 


4 


Bucket Leak rate 


Bucket Leak rate/1 1 .3.4 


M 


TLV 


4 


Bucket Full Ratio 


Bucket Full Ratio/1 1 .3.46 


C 


TLV 


3 


Flow Control 
Granularity (note) 


Flow Control 
Granularity/11.3.102 





TLV 


3 


NOTE:The Flow Control Granularity shall be provided in case the Gigabit Interface 
feature is negotiated. 



1 0.4.7 FLOW-CONTROL-MS-ACK 

This PDU informs the flow control mechanism at the BSS that the SGSN has received the FLOW -CONTROL-MS PDU 
indicated by the TLLI and the Tag. 



PDU type: 
Direction: 



FLOW-CONTROL-MS-ACK 
SGSN to BSS 

Table 10.4.7: FLOW-CONTROL-MS-ACK PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1 .3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


Tag 


Tag/1 1 .3.34 


M 


TLV 


3 



10.4.8 BVC-BLOCK 

This PDU indicates that the contained BVC shall be blocked at the recipient entity. 
PDU type: BVC-BLOCK 

Direction: BSS to SGSN 

Table 10.4.8: BVC-BLOCK PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


BVC! 


BVCI/1 1.3.6 


M 


TLV 


4 


Cause 


Cause/11.3.8 


M 


TLV 


3 



10.4.9 BVC-BLOCK-ACK 

This PDU acknowledges that a BVC has been blocked. 
PDU type: BVC-BLOCK-ACK 

Direction: SGSN to BSS 

Table 10.4.9: BVC-BLOCK-ACK PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


BVC! 


BVCI/1 1.3.6 


M 


TLV 


4 



£75/ 



3GPP TS 48.018 version 11.3.0 Release 11 



107 



ETSI TS 148 018 V1 1.3.0 (2013-07) 



10.4.10 BVC-UNBLOCK 

This PDU indicates that the identified BVC shall be unblocked at the recipient entity. 
PDU type: BVC-UNBLOCK 

Direction: BSS to SGSN 

Table 10.4.10: BVC-UNBLOCK PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1 .3.26 


M 


V 


1 


BVCI 


BVCI/11.3.6 


M 


TLV 


4 



10.4.11 BVC-UNBLOCK-ACK 

This PDU acknowledges that a BVC has been unblocked. 
PDU type: BVC-UNBLOCK-ACK 

Direction: SGSN to BSS 

Table 10.4.11: BVC-UNBLOCK-ACK PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/11 .3.26 


M 


V 


1 


BVCI 


BVCI/11.3.6 


M 


TLV 


4 



10.4.12 BVC-RESET 

This PDU indicates that BVC initialisation is required, e.g. because of a BVC failure. 
PDU type: BVC-RESET 

Direction: SGSN to BSS, BSS to SGSN 

Table 10.4.12: BVC-RESET PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1 .3.26 


M 


V 


1 


BVCI 


BVCI/11.3.6 


M 


TLV 


4 


Cause 


Cause/11.3.8 


M 


TLV 


3 


Cell Identifier (note 1) 




C 


TLV 


10 


Feature bitmap (note 2) 


Feature bitmap/1 1 .3.45 





TLV 


3 


Extended Feature 
Bitmap (note 3) 


Extended Feature 
Bitmap/1 1 .3.84 





TLV 


3 


NOTE 1 : The Cell Identifier IE is mandatory in the BVC-RESET PDU sent from BSS to 
SGSN in order to reset a BVC corresponding to a PTP functional entity. The 
Cell Identifier IE shall not be used in any other BVC-RESET PDU. 

NOTE 2: The Feature bitmap is only sent in a BVC-RESET PDU related to the 

signalling BVC. Absence of this IE implies no optional features are available 
over the NSE. 

NOTE 3: The Extended Feature Bitmap is only sent in a BVC-RESET PDU related to 
the signalling BVC. 



10.4.13 BVC-RESET-ACK 

This PDU indicates that BVC initialisation has been executed. 
PDU type: BVC-RESET-ACK 
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Direction: 



BSS to SGSN, SGSN to BSS 



Table 10.4.13: BVC-RESET-ACK PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1 .3.26 


M 


V 


1 


BVCI 


BVCI/11.3.6 


M 


TLV 


4 


Cell Identifier (note 1) 




C 


TLV 


10 


Feature bitmap (note 2) 


Feature bitmap/1 1 .3.45 





TLV 


3 


Extended Feature Bitmap 
(note 3) 


Extended Feature 
Bitmap/1 1 .3.84 





TLV 


3 


NOTE 1 : The Cell Identifier IE is mandatory in the BVC-RESET-ACK PDU sent from BSS to 
SGSN in response to reset a BVC corresponding to a PTP functional entity. The Cell 
Identifier IE shall not be used in any other BVC-RESET-ACK PDU. 

NOTE 2: The Feature bitmap is only sent in a BVC-RESET-ACK PDU related to the signalling 
BVC. Absence of this IE implies no optional features are available over the NSE. 

NOTE 3: The Extended Feature Bitmap is only sent in a BVC-RESET-ACK PDU related to the 
signalling BVC. 



10.4.14 STATUS 

This PDU indicates that an exception condition occurred. 
PDU type: STATUS 

Direction: SGSN to BSS, BSS to SGSN 



Table 10.4.14: STATUS PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


Cause 


Cause/11.3.8 


M 


TLV 


3 


BVCI 


BVCI/11.3.6 


C 


TLV 


4 


PDU In Error (note) 


PDU In Error/11.3.24 





TLV 


3-? 


NOTE: This is the whole PDU (starting with the [PDU type]) within which an error 
was detected. This PDU may be truncated if it exceeds the information 
carrying capacity of the underlying network service. 



1 0.4.1 4.1 Static conditions for BVCI 

The "BVCI" IE shall be included when the "Cause" IE is set to one of the following values: 

a) "BVCI blocked"; 

b) "BVCI unknown"; 

and shall not be included otherwise. 

10.4.15 SGSN-INVOKE-TRACE 

This PDU indicates that the BSS shall begin the production of a trace record for an MS. 
PDU type: SGSN-INVOKE-TRACE 

Direction: SGSN to BSS 

Table 10.4.15: SGSN-INVOKE-TRACE PDU content 



Information elements Type / Reference Presence Format Length 
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PDU type 


PDU type/1 1 .3.26 


M 


V 


1 


Trace Type 


Trace Type/1 1 .3.38 


M 


TLV 


3 


Trace Reference 


Trace Reference/1 1 .3.37 


M 


TLV 


4 


Trigger Id 


Trigger Id/11.3.40 





TLV 


4-24 


Mobile Id 


Mobile Id/1 1.3.20 





TLV 


3-10 


OMCId 


OMC Id/11.3.23 





TLV 


4-24 


TransactionId 


Transactionld/1 1.3.39 





TLV 


4 



10.4.16 DOWNLOAD-BSS-PFC 

This PDU requests a SGSN to initiate a CREATE-BSS-PFC procedure. 
PDU type: DOWNLOAD-BSS-PFC 

Direction: ESS to SGSN 

Table 10.4.16: DOWNLOAD-BSS-PFC PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1 .3.26 


M 


V 


1 


TLLI 


TLLI/1 1.3.35 


M 


TLV 


6 


PFI 


PFI/1 1.3.42 


M 


TLV 


3 



10.4.17 CREATE-BSS-PFC 

This PDU allows the SGSN to request that a ESS create or modify a ESS Packet Flow Context. 
PDU type: CREATE-ESS-PFC 

Direction: SGSN to ESS 

Table 10.4.17: CREATE-BSS-PFC PDU content 



Information elements 



Type / Reference 



Presence | Format | Length 
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PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


IMSI 


IMSI/11.3.14 


(note 4) 


TLV 


5-10 


PFI 


PFI/11.3.42 


M 


TLV 


3 


PFT 


GPRS Timer/1 1.3.44 


M 


TLV 


3 


ABQP 


ABQP/1 1 .3.43 


M 


TLV 


13-? 


Service UTRAN CCO 


Service UTRAN CCO/1 1 .3.47 





TLV 


3 


MS Radio Access 
Capability 


MS Radio Access 
Capability/11.3.22 


0(note 1) 


TLV 


7-? 


Allocation/Retention 
Priority 


Priority/11.3.27 





TLV 


3 


T10 


GPRS Timer/1 1.3.44 


C (note 2) 


TLV 


3 


Inter RAT Handover 
Info 


Inter RAT Handover 
Info/11.3.94 


(note 3) 


TLV 


3-? 


E-UTRAN Inter RAT 
Handover Info 


E-UTRAN Inter RAT Handover 
Info/11.3.104 


(note 3) 


TLV 


3-? 


Subscriber Profile ID for 
RAT/Frequency priority 
(note 5) 


Subscriber Profile ID for 

RAT/Frequency 

priority/11.3.105 





TLV 


3 


NOTE 1 : This Information Element shall be present if there is valid MS Radio Access 

Capability information known by the SGSN. 
NOTE 2: This information element shall be present if the Allocation/Retention Priority IE is 

present and if queuing is allowed for the PFC. 
NOTE 3: This information element shall be present if available in the SGSN. 
NOTE 4: This information element shall be present if the IMSI is available in the SGSN. 
NOTE 5: This IE may be included if available in the SGSN. If the Service UTRAN CCO IE 

is present with the value of "shall not" the Service UTRAN CCO IE takes 

precedence over this IE. 



10.4.18 CREATE-BSS-PFC-ACK 

This PDU allows the BSS to acknowledge a request from the SGSN for the creation or modification of a BSS Packet 
Flow Context. 

PDU type: CREATE-BSS-PFC-ACK 

Direction: BSS to SGSN 

Table 10.4.18: CREATE-BSS-PFC-ACK PDU content 



Information 
elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


PFI 


PFI/11.3.42 


M 


TLV 


3 


ABQP 


ABOP/1 1.3.43 


M 


TLV 


13-? 


Cause 


Cause/1 1 .3.8 





TLV 


3 



10.4.19 CREATE-BSS-PFC-NACK 

This PDU allows the BSS to Nack a request from the SGSN for the creation of a BSS Packet Flow Context. 
PDU type: CREATE-BSS-PFC-NACK 

Direction: BSS to SGSN 

Table 10.4.19: CREATE-BSS-PFC-NACK PDU content 



[Information elements] Type / Reference 



Presence | Format | Length 
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PDU type 


PDU type/11 .3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


PFI 


PFI/11.3.42 


M 


TLV 


3 


Cause 


Cause/11.3.8 


M 


TLV 


3 



10.4.20 MODIFY-BSS-PFC 

This PDU allows the BSS to request a modification of a BSS Packet Flow Context. 
PDU type: MODIFY-BSS-PFC 

Direction: BSS to SGSN 

Table 10.4.20: MODIFY-BSS-PFC PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


PFI 


PFI/11.3.42 


M 


TLV 


3 


ABQP 


ABQP/1 1 .3.43 


M 


TLV 


13-? 



10.4.21 MODIFY-BSS-PFC-ACK 

This PDU allows the SGSN to acknowledge a modification to a BSS Packet Flow Context. 
PDU type: MODIFY-BSS-PFC-ACK 

Direction: SGSN to BSS 

Table 10.4.21: MODIFY-BSS-PFC-ACK PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


PFI 


PFI/11.3.42 


M 


TLV 


3 


PFT 


GPRS Timer/1 1.3.44 


M 


TLV 


3 


ABQP 


ABQP/1 1 .3.43 


M 


TLV 


13-? 



10.4.22 DELETE-BSS-PFC 

This PDU allows the SGSN to request that a BSS delete a BSS Packet Flow Context. 
PDU type: DELETE-BSS-PFC 



Direction: 



SGSN to BSS 

Table 10.4.22: DELETE-BSS-PFC PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1 .3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


PFI 


PFI/11.3.42 


M 


TLV 


3 



10.4.23 DELETE-BSS-PFC-ACK 

This PDU allows the BSS to acknowledge a request for the deletion of a BSS Packet Flow Context. 
PDU type: DELETE-BSS-PFC-ACK 
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Direction: 



BSS to SGSN 

Table 10.4.23: DELETE-BSS-PFC-ACK PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1 .3.26 


M 


V 


1 


ILL! 


TLLI/1 1.3.35 


M 


TLV 


6 


PFI 


PFI/1 1.3.42 


M 


TLV 


3 



10.4.24 FLOW-CONTROL-PFC 

This PDU provides the SGSN with flow control information regarding one or more PFC(s) of a given Mobile Station. 
PDU type: FLOW-CONTROL-PFC 

Direction: BSS to SGSN 

Table 10.4.24: FLOW-CONTROL-PFC PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/1 1.3.35 


M 


TLV 


6 


Tag 


Tag/1 1 .3.34 


M 


TLV 


3 


MS Bucket Size 


MS Bucket Size/11.3.21 





TLV 


4 


Bucket Leak rate 


Bucket Leak rate/1 1 .3.4 





TLV 


4 


Bucket Full Ratio 


Bucket Full Ratio/1 1 .3.46 





TLV 


3 


PFC flow control parameters 


PFC flow control parameters/1 1 .3.68 


M 


TLV 




Flow Control Granularity 
(note) 


Flow Control Granularity/1 1 .3.1 02 





TLV 


3 


NOTE: The Flow Control Granularity shall be provided in case the Gigabit Interface feature is 
negotiated. 



10.4.25 FLOW-CONTROL-PFC-ACK 

This PDU informs the flow control mechanism at the BSS that the SGSN has received the FLOW-CONTROL-PFC 
PDU indicated by the TLLI and the Tag. 



PDU type: 
Direction: 



FLOW-CONTROL-PFC-ACK 
SGSN to BSS 

Table 10.4.25: FLOW-CONTROL-PFC-ACK PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/1 1.3.35 


M 


TLV 


6 


Tag 


Tag/1 1 .3.34 


M 


TLV 


3 



10.4.26 DELETE-BSS-PFC-REQ 

This PDU allows the BSS to inform the SGSN that the BSS Packet Flow Context cannot be supported anymore 
PDU type: DELETE-BSS-PFC-REQ 

Direction: BSS to SGSN 

Table 10.4.26: DELETE-BSS-PFC-REQ PDU content 



Information elements Type / Reference Presence Format Length 
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PDU type 


PDU type/11 .3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


PFI 


PFI/11.3.42 


M 


TLV 


3 


Cause 


Cause/11.3.8 


M 


TLV 


3 



10.4.27 PS-HANDOVER-REQUIRED 

This PDU initiates the allocation of resources in the target system for an MS. 
PDU type: PS-HANDOVER-REQUIRED 

Direction: BSS to SGSN 

Table 10.4.27: PS-HANDOVER-REQUIRED PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


Cause 


Cause/11.3.8 


M 


TLV 


3 


Source Cell Identifier 


Cell Identifier/11.3.9 


M 


TLV 


10 


Target Cell Identifier (note 
2) 


Cell Identifier/11.3.9 


C 


TLV 


10 


Source BSS to Target BSS 
Transparent Container 
(note 1) 


Source BSS to Target BSS 
Transparent Container/1 1 .3.79 


C 


TLV 


10-? 


Target RNC Identifier (note 
2) (note 3) 


RNC Identifier/11.3.87 


C 


TLV 


10 


Source to Target 
Transparent Container 
(note 1) 


Source to Target Transparent 
Container/11.3.85 


C 


TLV 


3-? 


Active PFCs List 


Active PFCs List/1 1.3.95c 


M 


TLV 


3-? 


Target eNB identifier (note 
2) (note 3) 


eNB Identifier/1 1.3.103 


C 


TLV 


3-n 


Reliable Inter RAT 
Handover Info (note 4) 


Reliable Inter RAT Handover 
Info/11.3.107 


C 


TLV 


3 


CSG Identifier (note 5) 


CSG Identifier/11.3.109 


c 


TLV 


7 


TAC (note 6) 


Tracking Area Code/1 1 .3.1 1 


c 


TLV 


5 


NOTE 1 : One and only one of these two conditional lEs shall be present depending on the 
target RAT as specified in subclause 8a.4. 


NOTE 2: One and only one of these three conditional lEs shall be present depending on the 
target RAT as specified in subclause 8a.4. 


NOTE 3: In case of PS handover to E-UTRAN, the Target RNC Identifier IE (carrying the 

Corresponding RNC-ID) may be present as an alternative to the Target eNB identifier 
IE. 


NOTE 4: This IE shall be present when the target cell is a GERAN cell. 


NOTE 5: This IE shall be present when the target cell is a CSG or hybrid cell. 


NOTE 6: This IE shall be present when the target cell is a E-UTRAN CSG or hybrid cell. 



10.4.28 PS-HANDOVER-REQUIRED-ACK 

This PDU indicates that resources have been allocated in the target system and that the BSS may initiate the channel 
change attempt for the corresponding MS. 

PDU type: PS-HANDOVER-REQUIRED-ACK 

Direction: SGSN to BSS 

Table 10.4.28: PS-HANDOVER-REQUIRED-ACK PDU content 



Information elements Type / Reference Presence Format Length 
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PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


List of set-up PFCs 


List of set-up PFCs/1 1 .3.83 


M 


TLV 


3-? 


Target BSS to Source BSS 
Transparent Container 
(note) 


Target BSS to Source BSS 
Transparent Container/1 1 .3.80 


C 


TLV 


3-? 


Target to Source 
Transparent Container 
(note) 


Target to Source Transparent 
Container/11.3.86 


C 


TLV 


3-? 


NOTE: One and only one of these two conditional IBs shall be present depending on the 
target RAT as specified in subclause 8a.4. 



1 0.4.29 PS-HANDOVER-REQUIRED-NACK 

This PDU informs the source BSS about failed resource allocation in the target system. 
PDU type: PS-HANDOVER-REQUIRED-NACK 

Direction: SGSN to BSS 

Table 10.4.29: PS-HANDOVER-REQUIRED-NACK PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1 .3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


Cause 


Cause/11.3.8 


M 


TLV 


3 



10.4.30 PS-HANDOVER-REQUEST 

This PDU initiates the allocation of resources for one or more PFCs in the target BSS for an MS. 
PDU type: PS-HANDOVER-REQUEST 

Direction: SGSN to BSS 

Table 10.4.30: PS-HANDOVER-REQUEST PDU content 



Information elements 



Type / Reference 



Presence | Format | Length 
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PDU type 


PDU type/11 .3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


IMSI 


IMSI/11.3.14 


M 


TLV 


5-10 


Cause 


Cause/11.3.8 


M 


TLV 


3 


Source Cell Identifier (note 
1) 


Cell Identifier/11.3.9 


C 


TLV 


10 


Source RNC Identifier (note 
1) 


RNC Identifier/11.3.87 


C 


TLV 


10 


Target Cell Identifier 


Cell Identifier/11.3.9 


M 


TLV 


10 


Source BSS to Target BSS 
Transparent Container 


Source BSS to Target BSS 
Transparent Container/1 1 .3.79 


M 


TLV 


7-? 


PFCs to be set-up list 


PFCs to be set-up list/1 1 .3.82 


M 


TLV 


22-? 


NAS container for PS 
Handover 


NAS container for PS 
Handover/11.3.81 





TLV 


3-? 


Service UTRAN CCO 


Service UTRAN CCO/1 1 .3.47 





TLV 


3 


Subscriber Profile ID for 
RAT/Frequency priority 
(note 2) 


Subscriber Profile ID for 
RAT/Frequency priority 
/1 1.3.105 





TLV 


3 


Reliable Inter RAT 
Handover Info (note 3) 


Reliable Inter RAT Handover 
Info/11.3.107 


C 


TLV 


3 


NOTE 1 : In case of PS handover from GERAN or UTRAN, one and only one of these two 
conditional lEs shall be present depending on the source RAT. In case of PS 
handover from E-UTRAN, neither of these two conditional lEs shall be present. 

NOTE 2: This IE may be included if available in the SGSN. If the Service UTRAN CCO IE is 
present with the value of "shall not" the Service UTRAN CCO IE takes precedence 
over this IE. 

NOTE 3: This IE shall be included if sent by the source BSS. 



10.4.31 PS-HANDOVER-REQUEST-ACK 

This PDU acknowledges the successful allocation of resources in the target BSS. 
PDU type: PS-HANDOVER-REQUEST-ACK 

Direction: BSS to SGSN 

Table 10.4.31: PS-HANDOVER-REQUEST-ACK PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


List of set-up PFCs 


List of set-up PFCs/1 1 .3.83 


M 


TLV 


3-? 


Target BSS to Source BSS 
Transparent Container 


Target BSS to Source BSS 
Transparent Container/1 1 .3.80 


M 


TLV 


3-? 



10.4.32 PS-HANDOVER-REQUEST-NACK 

This PDU informs the SGSN about failed resource allocation in the target BSS. 
PDU type: PS-HANDOVER-REQUEST-NACK 

Direction: BSS to SGSN 

Table 10.4.32: PS-HANDOVER-REQUEST-NACK PDU content 



Information elements Type / Reference Presence Format Length 
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PDU type 


PDU type/1 1 .3.26 


M 


V 


1 


TLLI 


TLLI/1 1.3.35 


M 


TLV 


6 


Cause 


Cause/11.3.8 


M 


TLV 


3 



10.4.33 PS-HANDOVER-COMPLETE 

This PDU informs the SGSN about successful channel change for an MS. 
PDU type: PS-HANDOVER-COMPLETE 

Direction: BSS to SGSN 

Table 10.4.33: PS-HANDOVER-COMPLETE PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/1 1.3.35 


M 


TLV 


6 


IMS! 


IMSI/11.3.14 


M 


TLV 


5-10 


Target Cell Identifier 
(note 1) 


Cell Identifier/11.3.9 





TLV 


10 


Request for Inter RAT 
Handover Info (note 2) 


Request for Inter RAT 
Handover Info/11.3.106 


C 


TLV 


3 


NOTE 1 : The Target Cell Identifier IE is included only for optimised Intra-BSS PS 

Handover. 
NOTE 2: This IE shall be included if the BSS supports inter-RAT PS handover to 

UTRAN and/or E-UTRAN. 



10.4.34 PS-HANDOVER-CANCEL 

This PDU cancels the handover for an MS. 

PDU type: PS-HANDOVER-CANCEL 

Direction: BSS to SGSN 



Table 10.4.34: PS-HANDOVER-CANCEL PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/1 1.3.35 


M 


TLV 


6 


Cause 


Cause/11.3.8 


M 


TLV 


3 


Source Cell Identifier 


Cell ldentifier/1 1.3.9 


M 


TLV 


10 


Target Cell Identifier 
(note 1) 


Cell Identifier/11.3.9 


C 


TLV 


10 


Target RNC Identifier 
(note 1) (note 2) 


RNC Identifier/11.3.87 


C 


TLV 


10 


Target eNB Identifier 
(note 1) (note 2) 


eNB Identifier/1 1.3.103 


c 


TLV 


3-n 


NOTE 1 : One and only one of these three conditional lEs shall be present depending 
on the target RAT as specified in subclause 8a.7. 


NOTE 2: In case of PS handover to E-UTRAN, the Target RNC Identifier IE (carrying 
the Corresponding RNC-ID) may be present as an alternative to the Target 
eNB identifier IE. 



10.4.35 PS-HANDOVER-COMPLETE-ACK 

This PDU provides to the BSS the Inter RAT Handover Info IE or E-UTRAN Inter RAT Handover Info IE or both. It is 
sent only if requested by the BSS and it shall contain at least one of the inter-RAT capabilities. 

PDU type: PS-HANDOVER-COMPLETE-ACK 

Direction: SGSN to BSS 



£75/ 



3GPP TS 48.018 version 11.3.0 Release 11 



117 



ETSI TS 148 018 V1 1.3.0 (2013-07) 



Table 10.4.35: PS-HANDOVER-COMPLETE-ACK PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


Inter RAT Handover 
Info 


Inter RAT Handover 
Info/11.3.94 


C(note 1) 


TLV 


3-? 


E-UTRAN Inter RAT 
Handover Info 


E-UTRAN Inter RAT 
Handover Info/11.3.104 


C(note 1) 


TLV 


3-? 


NOTE 1 : At least one of these lEs shall be present depending on whether the BSS 

requested Inter RAT Handover Info or E-UTRAN Inter RAT Handover Info or 
both. 



10.4.36 OVERLOAD 

This PDU informs the BSS that the SGSN sending the PDU is in an overload situation and the signalhng traffic to the 
SGSN should be reduced. 



PDU type: 
Direction: 



OVERLOAD 
SGSN to BSS 



Table 10.4.36: OVERLOAD PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


Priority Class Indicator 


Priority Class 
Indicator/11.3.118 


M 


TLV 


3 



1 0.5 PDU functional definitions and contents at LCS SAP 



1 0.5.1 PERFORIVI-LOCATION-REQUEST 

This PDU allows the SGSN to request the BSS to perform a location procedure for the target MS. 
PDU type: PERFORM-LOCATION-REQUEST 

Direction: SGSN to BSS 

Table 10.5.1: PERFORM-LOCATION-REQUEST PDU content 



Information elements 



Type / Reference 



Presence | Format | Length 
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Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.S.26 


M 


V 


1 


TLLI 


TLLI/1 1.3.35 


M 


TLV 


6 


IMSI 


IMSI/11.S.14 


M 


TLV 


5-10 


DRX Parameters (note 1) 


DRX Parameters/11 .3.11 





TLV 


4 


BVCI (PCU-PTP) 


BVCI/1 1.3.6 


M 


TLV 


4 


NSEI (PCU-PTP) 


NSEI/1 1.3.48 


M 


TLV 


4-? 


Location Type 


Location Type/1 1 .3. S3 


M 


TLV 


3-? 


Cell Identifier 


Cell Identifier/11.3.9 


M 


TLV 


10 


LCS Capability (note 2) 


LCS Capability/1 1.3.S9 





TLV 


3-? 


LCS Priority 


LCS Priority/11.3.57 





TLV 


3-? 


LCS QoS 


LCSQ0S/II.3.SO 





TLV 


3-? 


LCS Client Type (note 3) 


LCS Client Type/1 1.3.51 


C 


TLV 


3-? 


Requested GPS Assistance Data (note 4) 


Requested GPS Assistance Data/1 1 .3.52 





TLV 


3-? 


IMEI (note 5) 


IMEI/1 1.3.91 





TLV 


10 


GANSS Location Type 


GANSS Location Type / 1 1 .3.100 


C 


TLV 


3 


Requested GANSS Assistance Data (note 
6) 


Requested GANSS Assistance 
Data/1 1 .3.99 





TLV 


3-? 


N0TE1 
NOTE 2 
NOTES 
NOTE 4 
NOTES 

NOTE 6 


This IE is present if the SGSN has valid DRX Parameters for the TLLI. 

This IE is present if the SGSN has received the information from the MS. 

This IE is present if the location type indicates a request for a location estimate and is optional otherwise. 

This IE is present if GPS assistance data is requested. 

The IMEI could be sent in addition to the IMSI for the purpose of allowing correlation between the two 

identities. 

This IE is present if GANSS assistance data is requested. 



1 0.5.2 PERFORM-LOCATION-RESPONSE 

This PDU allows the BSS to respond to the SGSN after the completion of the location procedure. 
PDU type: PERFORM-LOCATION-RESPONSE 

Direction: BSS to SGSN 

Table 10.5.2: PERFORM-LOCATION-RESPONSE PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/1 1.3.3S 


M 


TLV 


6 


BVCI (PCU-PTP) 


BVCI/1 1.3.6 


M 


TLV 


4 


Location Estimate (note 1 ) 


Location Estimate/11.3.54 


C 


TLV 


3-? 


Positioning Data 


Positioning Data/1 1.3. 55 





TLV 


3-? 


Deciphering Keys (note 2) 


Deciphering Keys/1 1 .3.56 


C 


TLV 


3-? 


LCS Cause (note 3) 


LCS Cause/11.3.58 





TLV 


3-? 


Velocity Data 


Velocity Data/1 1 .3.96 





TLV 


3-? 


GANSS Positioning Data 


GANSS Positioning Data/ 
11.3.101 





TLV 


3-? 


NOTE 1 : This IE is present if the location of the target MS was requested and the 

procedure succeeded. 
NOTE 2: This IE is present if the deciphering keys were requested and the procedure 

succeeded. 
NOTE 3: This IE is present if the procedure failed. 



1 0.5.3 PERFORM-LOCATION-ABORT 

This PDU allows the SGSN to request the BSS to ABORT the LCS procedure. 
PDU type: PERFORM-LOCATION-ABORT 

Direction: SGSN to BSS 

Table 10.5.3: PERFORM-LOCATION-ABORT PDU content 
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Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/11 .3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


BVCI (PCU-PTP) 


BVCI/11.3.6 


M 


TLV 


4 


LCS Cause 


LCS Cause/1 1 .3.58 


M 


TLV 


3-? 



1 0.5.4 POSITION-COMMAND 

This PDU allows the BSS to request the SGSN to perform the position command procedure. 
PDU type: POSITION-COMMAND 

Direction: BSS to SGSN 

Table 10.5.4: POSITION-COMMAND PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


BVCI (PCU-PTP) 


BVCI/11.3.6 


M 


TLV 


4 


RRLP Flags 


RRLP Flags/11.3.60 


M 


TLV 


3 


RRLPAPDU 


RRLP APDU/1 1.3.49 


M 


TLV 


3-? 



1 0.5.5 POSITION-RESPONSE 

This PDU allows the SGSN to respond to the position command request procedure. 
PDU type: POSITION-RESPONSE 

Direction: SGSN to BSS 

Table 10.5.5: POSITION-RESPONSE PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TLLI 


TLLI/11.3.35 


M 


TLV 


6 


BVCI (PCU-PTP) 


BVCI/11.3.6 


M 


TLV 


4 


RRLP Flags a) 


RRLP Flags/1 1.3.60 


C 


TLV 


3 


RRLPAPDU a) 


RRLP APDU/1 1.3.49 


C 


TLV 


3-? 


LCS Cause b) 


LCS Cause/11.3.58 





TLV 


3-? 


a) This IE is present if the procedure succeeded. 

b) This IE is present if the procedure failed. 



1 0.6 PDU functional definitions and contents at RIIVI SAP 
1 0.6.1 RAN-INFORMATION-REQUEST 

The RAN-INFORMATION-REQUEST PDU allows a controlhng BSS to request information from another BSS. 
PDU type: RAN-INFORMATION-REQUEST 



Direction: 



BSS to SGSN 
SGSN to BSS 
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Table 10.6.1: RAN-INFORMATION-REQUEST PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/11 .3.26 


M 


V 


1 


Destination Cell Identifier 


RIIVI Routing Information/11.3.70 


M 


TLV 


3-? 


Source Cell Identifier 


RIIVI Routing Information/11.3.70 


M 


TLV 


3-? 


RIM Container 


RAN-INFORMATION-REQUEST RIM 
Container/11. 3. 62a.1 


M 


TLV 


3-? 



1 0.6.2 RAN-INFORMATION 

The RAN-INFORMATION PDU allows a serving BSS to send information to a controlling BSS. 
PDU type: RAN-INFORMATION 



Direction: 



BSS to SGSN 
SGSN to BSS 



Table 10.6.2: RAN-INFORMATION-PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


Destination Cell Identifier 


RIM Routing Information/11.3.70 


M 


TLV 


3-? 


Source Cell Identifier 


RIM Routing Information/11.3.70 


M 


TLV 


3-? 


RIM Container 


RAN-INFORMATION RIM 
Container/11. 3. 62a.2 


M 


TLV 


3-? 



1 0.6.3 RAN-INFORMATION-ACK 

The RAN-INFORMATION-ACK PDU allows a controlling BSS to acknowledge the reception of a RAN- 
INFORMATION PDU and a serving BSS to acknowledge the reception of a RAN-INFORMATION-APPLICATION- 
ERROR PDU. 

PDU type: RAN-INFORMATION-ACK 

Direction: BSS to SGSN 

SGSN to BSS 

Table 10.6.3: RAN-INFORMATION-ACK PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


Destination Cell Identifier 


RIM Routing Information/11.3.70 


M 


TLV 


3-? 


Source Cell Identifier 


RIM Routing Information/11.3.70 


M 


TLV 


3-? 


RIM Container 


RAN-INFORMATION-ACK RIM 
Container/11. 3. 62a.3 


M 


TLV 


3-? 
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1 0.6.4 RAN-INFORMATION-ERROR 

The RAN-INFORMATION-ERROR PDU allows a BSS to send an error PDU back to an originating BSS as a response 
to a RAN-INFORMATION, a RAN-INFORMATION-REQUEST, a RAN-INFORMATION-ACK or a RAN- 
INFORMATION-APPLICATION-ERRORPDU. 

PDU type: RAN-INFORMATION-ERROR 

Direction: BSS to SGSN 

SGSN to BSS 



Table 10.6.4: RAN-INFORMATION-ERROR content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


Destination Cell Identifier 


RIIVI Routing Information/11.3.70 


M 


TLV 


3-? 


Source Cell Identifier 


RIM Routing Information/11.3.70 


M 


TLV 


3-? 


RIM Container 


RAN-INFORMATION-ERROR 
RIM Container/11 .3.62a.4 


M 


TLV 


3-? 



1 0.6.5 RAN-INFORMATION-APPLICATION-ERROR 

The RAN-INFORMATION-APPLICATION-ERROR PDU allows a controlUng BSS to inform the serving BSS about 
erroneous application information in a previously received RAN-INFORMATION PDU. 

PDU type: RAN-INFORMATION-APPLICATION-ERROR 

Direction: BSS to SGSN 

SGSN to BSS 

Table 10.6.5: RAN-INFORMATION-APPLICATION-ERROR PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/11 .3.26 


M 


V 


1 


Destination Cell Identifier 


RIM Routing Information/11.3.70 


M 


TLV 


3-? 


Source Cell Identifier 


RIM Routing Information/11.3.70 


M 


TLV 


3-? 


RIM Container 


RAN-INFORMATION-APPLICATION- 
ERROR RIM Container/1 1.3.62a.5 


M 


TLV 


3-? 



1 0.7 PDU functional definitions and contents at IVIBIVIS SAP 
10.7.1 IVIBIVIS-SESSION-START-REQUEST 

This PDU allows a SGSN to request BSS to start an MBMS session. 
PDU type: MBMS-SESSION-START-REQUEST 

Direction: SGSN to BSS 
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Table 10.7.1: MBMS-SESSION-ST ART-REQUEST PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TMGI 


TMGI/11.3.77 


M 


TLV 


3-8 


MBMS Session Identity 


IVIBMS Session Identity/1 1 .3.71 





TLV 


3 


ABQP 


ABQP/1 1.3.43 


M 


TLV 


13-? 


IVIBIVIS Service Area Identity List 


MBMS Service Area Identity List/1 1 .3.73 


M 


TLV 


4-? 


IVIBIVIS Routing Area List 


MBMS Routing Area List/1 1 .3.75 


M 


TLV 


3-? 


IVIBIVIS Session Duration 


MBMS Session Duration/1 1 .3.72 


M 


TLV 


3-? 


IVIBMS Session Information 


MBMS Session Information/11.3.76 


M 


TLV 


3 


Time to IVIBIVIS Data Transfer 


Time to MBMS Data Transfer/1 1 .3.92 


M 


TLV 


3 


Allocation/Retention Priority 


Priority/1 1 .3.27 





TLV 


3 


IVIBMS Session Repetition Number 


MBMS Session Repetition Number/11.3.93 





TLV 


3 



1 0.7.2 MBMS-SESSION-START-RESPONSE 

This PDU allows a BSS to acknowledge to SGSN that it will start an MBMS session or to indicate to SGSN why the 
MBMS Service Context cannot be created or is released by the BSS. 

PDU type: MBMS-SESSION-START-RESPONSE 

Direction: BSS to SGSN 

Table 10.7.2: MBMS-SESSION-START-RESPONSE PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TMGI 


TMGI/11.3.77 


M 


TLV 


3-8 


MBMS Session Identity 


MBMS Session Identity/ 1 1 .3.71 





TLV 


3 


MBMS Response 


MBMS Response/ 1 1 .3.74 


M 


TLV 


3 



1 0.7.3 MBMS-SESSION-STOP-REQUEST 

This PDU allows a SGSN to request BSS to stop an MBMS session. 
PDU type: MBMS-SESSION-STOP-REQUEST 

Direction: SGSN to BSS 

Table 10.7.3: MBMS-SESSION-STOP-REQUEST PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TMGI 


TMGI/11.3.77 


M 


TLV 


3-8 


MBMS Session Identity 


MBMS Session Identity/ 1 1 .3.71 





TLV 


3 


MBMS Stop Cause 


MBMS Stop Cause/1 1.3.78 


M 


TLV 


3 



1 0.7.4 MBMS-SESSION-STOP-RESPONSE 

This PDU allows a BSS to acknowledge to SGSN that it will stop an MBMS session. 
PDU type: MBMS-SESSION-STOP-RESPONSE 

Direction: BSS to SGSN 
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Table 10.7.4: MBMS-SESSION-STOP-RESPONSE PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TMGI 


TMGI/ 11.3.77 


M 


TLV 


3-8 


MBMS Session Identity 


IVIBMS Session Identity/ 1 1 .3.71 





TLV 


3 


IVIBIVIS Response 


IVIBMS Response/ 1 1 .3.74 


M 


TLV 


3 



1 0.7.5 MBMS-SESSION-UPDATE-REQUEST 

This PDU allows an SGSN to request BSS to update the MBMS service area list of an ongoing MBMS broadcast 

service session. 

PDU type: MBMS-SESSION-UPDATE-REQUEST 

Direction: SGSN to BSS 

Table 10.7.5: MBMS-SESSION-UPDATE-REQUEST PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TMGI 


TMGI/1 1.3.77 


M 


TLV 


3-8 


MBMS Session Identity 


MBMS Session Identity/1 1 .3.71 





TLV 


3 


ABQP 


ABQP/1 1.3.43 


M 


TLV 


13-? 


MBMS Service Area Identity List 


MBMS Service Area Identity List/1 1 .3.73 


M 


TLV 


4-? 


MBMS Routing Area List 


MBMS Routing Area List/1 1 .3.75 


M 


TLV 


3-? 


MBMS Session Duration 


MBMS Session Duration/1 1 .3.72 


M 


TLV 


3-? 


MBMS Session Information 


MBMS Session Information/11.3.76 


M 


TLV 


3 


Time to MBMS Data Transfer 


Time to MBMS Data Transfer/1 1 .3.92 


M 


TLV 


3 


Allocation/Retention Priority 


Priority/1 1 .3.27 





TLV 


3 


MBMS Session Repetition Number 


MBMS Session Repetition Number/11.3.93 





TLV 


3 



1 0.7.6 MBMS-SESSION-UPDATE-RESPONSE 

This PDU allows a BSS to acknowledge to SGSN that it will update the MBMS service area list of an ongoing MBMS 
broadcast service session or to indicate to SGSN why the MBMS Service Context cannot be created or is released by 
the BSS. 

PDU type: MBMS-SESSION-UPDATE-RESPONSE 

Direction: BSS to SGSN 

Table 10.7.6: MBMS-SESSION-UPDATE-RESPONSE PDU content 



Information elements 


Type / Reference 


Presence 


Format 


Length 


PDU type 


PDU type/1 1.3.26 


M 


V 


1 


TMGI 


TMGI/ 11.3.77 


M 


TLV 


3-8 


MBMS Session Identity 


MBMS Session Identity/ 1 1 .3.71 





TLV 


3 


MBMS Response 


MBMS Response/ 1 1 .3.74 


M 


TLV 


3 



1 1 General information elements coding 

The figures and text in this sub-clause describe the Information Elements contents. 

11.1 General structure of the information elements 

Refer to General Structure Of The Information Elements/3GPP TS 48.016. 
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1 1 .2 Information element description 

Refer to Information Element Description/3GPP TS 48.016. 
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1 1 .3 Information Element Identifier (lEI) 

An Information Element Identifier (lEI) is identified by the same coding in all BSSGP PDUs. 

Table 11.3: lEI types 



lEI coding 
(hexadecimal) 


lEI Types 


xOO 


Alignment Octets 


x01 


Bmax default MS 


x02 


BSS Area Indication 


x03 


Bucket Leak Rate 


x04 


BVCI 


x05 


BVC Bucket Size 


x06 


BVC Measurement 


x07 


Cause 


x08 


Cell Identifier 


x09 


Channel needed 


xOa 


DRX Parameters 


xOb 


eMLPP-Priority 


xOc 


Flush Action 


xOd 


IMS! 


xOe 


LLC-PDU 


xOf 


LLC Frames Discarded 


x10 


Location Area 


x11 


Mobile Id 


x12 


MS Bucket Size 


x13 


MS Radio Access Capability 


x14 


OMCId 


x15 


PDU In Error 


x16 


PDU Lifetime 


x17 


Priority 


x18 


QoS Profile 


x19 


Radio Cause 


x1a 


RA-Cap-UPD-Cause 


x1b 


Routeing Area 


x1c 


R default MS 


x1d 


Suspend Reference Number 


x1e 


Tag 


x1f 


TLLI 


x20 


TMSI 


x21 


Trace Reference 


x22 


Trace Type 


x23 


Transactionid 


x24 


Trigger Id 


x25 


Number of octets affected 


x26 


LSA Identifier List 


x27 


LSA Information 


x28 


Packet Flow identifier 


x29 


GPRS Timer 


x3a 


Aggregate BSS QoS Profile (ABQP) 


x3b 


Feature Bitmap 


x3c 


Bucket Full Ratio 


x3d 


Service UTRAN CCO (Cell Change Order) 


x3e 


NSEI 


x3f 


RRLPAPDU 


x40 


LCS OoS 


x41 


LCS Client Type 


x42 


Requested GPS Assistance Data 


x43 


Location Type 


x44 


Location Estimate 


x45 


Positioning Data 


x46 


Deciphering Keys 
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lEI coding 
(hexadecimal) 


lEI Types 


x47 


LCS Priority 


x48 


LCS Cause 


x49 


LCS Capability 


x4a 


RRLP Flags 


x4b 


RIIVI Application Identity 


x4c 


RIM Sequence number 


x4d 


RAN-INFORMATION-REQUEST Application Container 


x4e 


RAN-INFORIVIATION Application Container 


x4f 


RIM PDU Indications 


x50 


This value is reserved for future use and shall be treated by the recipient 
as an unknown lEI 


x51 


This value should not be used, as it has been used in earlier versions of 
this protocol. 


x52 


PFC flow control parameters 


x53 


Global CN-ld 


x54 


RIM Routing Information 


x55 


RIM Protocol Version Number 


x56 


Application Error Container 


x57 


RAN-INFORMATION-REQUEST RIM Container 


x58 


RAN-INFORMATION RIM Container 


x59 


RAN-INFORMATION-APPLICATION-ERROR RIM Container 


x5a 


RAN-INFORMATION-ACK RIM Container 


x5b 


RAN-INFORMATION-ERROR RIM Container 


x5c 


TMGI 


x5d 


MBMS Session Identity 


x5e 


MBMS Session Duration 


x5f 


MBMS Service Area Identity List 


x60 


MBMS Response 


x61 


MBMS Routing Area List 


x62 


MBMS Session Information 


x63 


MBMS Stop Cause 


x64 


Source BSS to Target BSS Transparent Container 


x65 


Target BSS to Source BSS Transparent Container 


x66 


NAS container for PS Handover 


x67 


PFCs to be set-up list 


x68 


List of set-up PFCs 


x69 


Extended Feature Bitmap 


x6a 


Source to Target Transparent Container 


x6b 


Target to Source Transparent Container 


x6c 


RNC Identifier 


x6d 


Page Mode 


x6e 


Container ID 


x6f 


Global TFI 


x70 


IMEI 


x71 


Time to MBMS Data Transfer 


x72 


MBMS Session Repetition Number 


x73 


Inter RAT Handover Info 


x74 


PS Handover Command 


x75 


PS Handover Indications 


x76 


SI/PSI Container 


x77 


Active PFCs List 


x78 


Velocity Data 


x79 


DTM Handover Command 


x7a 


CS Indication 


x7b 


Requested GANSS Assistance Data 


x7c 


GANSS Location Type 


x7d 


GANSS Positioning Data 


x7e 


Flow Control Granularity 


x7f 


eNB Identifier 


x80 


E-UTRAN Inter RAT Handover Info 


x81 


Subscriber Profile ID for RAT/Frequency priority 


x82 


Request for Inter RAT Handover Info 
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lEI coding 
(hexadecimal) 


lEI Types 


x83 


Reliable Inter RAT Handover Info 


x84 


SON Transfer Application Identity 


x85 


CSG Identifier 


x86 


TAG 


x87 


Redirect Attempt Flag 


x88 


Redirection Indication 


x89 


Redirection Completed 


x8a 


Unconfirmed send state variable 


x8b 


IRAT Measurement Configuration 


x8c 


SCI 


X8d 


GGSN/P-GW location 


x8e 


Selected PLMN ID 


x8f 


Priority Class Indicator 



11.3.1 Alignment octets 

The Alignment Octets are used to align a subsequent lEI onto a 32 bit boundary. The element coding is: 

Table 1 1 .3.1 : Alignment octets IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator (note) 


octet 3-5 


spare octet 


NOTE: The Length Indicator may indicate that from to 3 spare octets are 
present. 



11.3.2 Bmax default MS 

This information element indicates the default bucket size (Bmax) in octets for an MS. The element coding is: 

Table 11.3.2: Bmax default MS IE 





8 


7 


6 


1 5 1 4 1 


3 


2 


1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-4 


Bmax 



The Bmax field is coded as Bmax of BVC Bucket Size, see sub-clause 11.3.5. 

1 1 .3.3 BSS Area Indication 

This element is used to indicate that the paging shall be done in all the cells within the BSS. The element coding is: 

Table 11.3.3: BSS Area Indication IE 





8 


7 


6 


1 5 1 4 1 


3 


2 


1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


BSS indicator 



The coding of octet 2 is a binary number indicating the Length of the remaining element. 
The coding of octet 3 shall not be specified. The recipient shall ignore the value of this octet. 
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1 1 .3.4 Bucket Leak Rate (R) 

This information element indicates the leak rate (R) to be applied to a flow control bucket. The element coding is: 

Table 11.3.4: Bucket Leak Rate IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


R Value (MSB) 


octet 4 


R Value (LSB) 



If the Gigabit Interface feature has not been negotiated, the R field is the binary encoding of the rate information 
expressed in 100 bits/s increments, starting from x 100 bits/s until 65 535 x 100 bits/s (6 Mbps). 

If the Gigabit Interface feature has been negotiated, the R field is the binary encoding of the rate information expressed 
in increments as defined by the Flow Control Granularity IE. 

1 1 .3.5 BVC Bucket Size 

This information element indicates the maximum bucket size (Bmax) in octets for a BVC. The element coding is: 

Table 11.3.5: BVC Bucket Size IE 





8 7 6 5 4 3 


2 1 1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


Bmax (MSB) 


octet 4 


Bmax (LSB) 



If the Gigabit Interface feature has not been negotiated, the Bmax field is the binary encoding of the bucket-size 
information expressed in 100 octet increments, starting from x 100 octets until 65 535 x 100 octets (6 Mbytes). 

If the Gigabit Interface feature has been negotiated, the Bmax field is the binary encoding of the rate information 
expressed in increments as defined by the Flow Control Granularity IE. 

1 1 .3.6 BVCI (BSSGP Virtual Connection Identifier) 

The BVCI identifies a BVC. The element coding is: 

Table 11.3.6: BVCI IE 





8 


7 


6 1 5 1 4 1 3 


2 


1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-4 


Unstructured value 



1 1 .3.7 BVC Measurement 

This information element describes average queuing delay for a BVC. The element coding is: 

Table 11.3.7: BVC Measurement IE 





8 


7 


6 1 5 1 4 1 3 


2 


1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3,4 


Delay Value (in centi-seconds) 
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The Delay Value field is coded as a 16-bit integer value in units of centi-seconds (one hundredth of a second). This 
coding provides a range of over 10 minutes in increments of 10 ms. As a special case, the hexadecimal value OxFFFF 
(decimal 65 535) shall be interpreted as "infinite delay". 

11.3.8 Cause 

The Cause information element indicates the reason for an exception condition. The element coding is: 

Table 11. 3.8.a: Cause IE 





8 


7 


6 


1 5 1 4 1 


3 


2 


1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


Cause value 
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Table 11.3.8.b: Cause coding 



Cause value 
Hexadecimal 


Semantics of coding 




All values not listed below shall be treated as 
"protocol error - unspecified" 


xOO 


Processor overload 


x01 


Equipment failure 


x02 


Transit network service failure 


x03 


Network service transmission capacity modified 
from zero kbps to greater than zero kbps 


x04 


Unknown IVIS 


x05 


BVCI unknown 


x06 


cell traffic congestion 


x07 


SGSN congestion 


x08 


O&IVI intervention 


x09 


BVCI-blocked 


xOa 


PFC create failure 


xOb 


PFC preempted 


xOc 


ABQP no more supported 


x20 


Semantically incorrect PDU 


x21 


Invalid mandatory information 


x22 


Missing mandatory IE 


x23 


IVIissing conditional IE 


x24 


Unexpected conditional IE 


x25 


Conditional IE error 


x26 


PDU not compatible with the protocol state 


x27 


Protocol error - unspecified 


x28 


PDU not compatible with the feature set 


x29 


Requested Information not available 


x2a 


Unknown Destination address 


x2b 


Unknown RIIVI Application Identity or RIM 
application disabled 


x2c 


Invalid Container Unit Information 


x2d 


PFC queuing 


x2e 


PFC created successfully 


x2f 


T12 expiry 


x30 


MS under PS Handover treatment 


x31 


Uplink quality 


x32 


Uplink strength 


x33 


Downlink quality 


x34 


Downlink strength 


x35 


Distance 


x36 


Better cell 


x37 


Traffic 


x38 


Radio contact lost with MS 


x39 


MS back on old channel 


x3a 


T13 expiry 


x3b 


T1 4 expiry 


x3c 


Not all requested PFCs created 


x3d 


CS cause 


x3e 


Requested ciphering and/or integrity protection 
algorithms not supported 


x3f 


Relocation failure in target system 


x40 


Directed Retry 


x41 


Time critical relocation 


x42 


PS Handover Target not allowed 


x43 


PS Handover not Supported in Target BSS or 
Target System 


x44 


Incoming relocation not supported due to 
PUESBINE feature 


x45 


DTM Handover - No CS resource 


x46 


DTM Handover - PS Allocation failure 


x47 


DTM Handover - T24 expiry 
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x48 


DTM Handover - Invalid CS Indication IE 


x49 


DTIVI Handover - T23 expiry 


x4a 


DTIVI Handover - MSC Error 


x4b 


Invalid CSG cell 


x80 to x87 


Reserved for further definition of non-critical PS 
handover cause values 



NOTE: If received, cause values x80 to x87 inclusive indicate a non-critical PS Handover (see sub-clause 8a.5). 

11.3.9 Cell Identifier 

This information element uniquely identifies one cell. The element coding is: 

Table 11.3.9: Cell Identifier IE 



octet 1 



octet 2, 2a 



octets 3-8 



octets 9-10 



lEI 



Length Indicator 



Octets 3 to 8 contain the value part (starting with octet 2) of the 
Routing Area Identification /E defined in 3GPP TS 24.008, not 
including 3GPP TS 24.008 lEI 



Octets 9 and 1 contain the value part (starting with octet 2) of the 
Cell Identity /£ defined in 3GPP TS 24.008, not including 
3GPPTS 24.008 lEI 



11.3.10 Channel needed 

This information element is coded as defined in 3GPP TS 29.018. It is relevant to circuit-switched paging requests. The 
element coding is: 

Table 11.3.10: Channel needed IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


Rest of element coded as the value part of the Channel Needed 
PDU defined in 3GPP TS 29.018, not including 3GPP TS 29.018 
lEI and 3GPP TS 29.018 length indicator 



11.3.11 DRX Parameters 

This information element contains MS specific DRX information. The element coding is: 

Table 1 1 .3.1 1 : DRX Parameters IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-n 


Rest of element coded as the value part defined in 
3GPP TS 24.008, not including 3GPP TS 24.008 lEI and 
3GPP TS 24.008 octet length indicator 



11.3.12 eMLPP-Priority 

This element indicates the eMLPP-Priority of a PDU. The element coding is: 

Table 11.3.12: eMLPP-Priority IE 
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8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


Rest of element coded as the value part of the eMLPP-Priority IE 
defined in 3GPP TS 48.008, not including 3GPP TS 48.008 lEI and 
3GPP TS 48.008 length indicator 



11.3.13 Flush Action 

The Flush action information element indicates to the SGSN the action taken by the BSS in response to the flush 
request. The element coding is: 

Table 11. 3.13.a: Flush Action IE 





8 7 


6 


5 


4 


3 


2 


1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


Action value 



Table 11.3.13.b: Action coding 



Action value 
Hexadecimal 


Semantics of coding 


xOO 


LLG-PDU(s) deleted 


x01 


LLC-PDU(s) transferred 




All values not explicitly shown are reserved for 
future use 



11.3.14 IMSI 

This information element contains the International Mobile Subscriber Identity (see 3GPP TS 23.003). The element 
coding is: 

Table 11.3.14: IMSI IE 





8 7 6 5 4 3 2 1 


octet 1 


IE! 


octet 2, 2a 


Length Indicator 


octet 3-n 


Octets 3-n contain an IMSI coded as the value part of the IVIobile 

Identity IE defined in 3GPP TS 24.008 

(N0TE1) 


NOTE 1 : The Type of identity f\e\d in the Mobile Identity IE shall be ignored by 
the receiver. 



11.3.15 LLC-PDU 

This information element contains an LLC-PDU. The element coding is: 

Table 11.3.15: LLC-PDU IE 





8 7 6 5 4 


3 1 2 1 1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


LLC-PDU (first part) 


octet n 


LLC-PDU (last part) 
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11 .3.1 6 LLC Frames Discarded 

This element describes the number of LLC frames that have been discarded inside a BSS. The element coding is: 

Table 11.3.16: LLC Frames Discarded IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


Number of frames discarded (in liexadecimal) 



11.3.17 Location Area 

This element uniquely identifies one Location Area. The element coding is: 

Table 11.3.17: Location Area IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Lengtii Indicator 


octets 3-7 


Octets 3 to 7 contain the value part (starting with octet 2) of the 
Location Area Identification /Edefined in 3GPP TS 24.008, not 
including 3GPP TS 24.008 lEI 



The coding of octet 2 is a binary number indicating the Length of the remaining element. 

11.3.18 LSA Identifier List 

This information element uniquely identifies LSAs. The element coding is: 

Table 11.3.18: LSA Identifier List IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-? 


Rest of element coded as in 3GPP TS 48.008, not including 
3GPP TS 48.008 lEI and 3GPP TS 48.008 length indicator 



11.3.19 LSA Information 

This information element uniquely identifies LSAs, the priority of each LSA and the access right outside these LSAs. 
The element coding is: 

Table 11.3.19: LSA Information IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-? 


Rest of element coded as in 3GPP TS 48.008, not including 
3GPP TS 48.008 lEI and 3GPP TS 48.008 length indicator 



11.3.20 Mobile Id 

The element coding is: 



Table 11.3.20: Mobile Id IE 
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8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-n 


Octets 3-n contain either the IIVISI, IIVIEISV or IIVIEI coded as the 
value part (starting with octet 3) of the Mobile Identity /£ defined in 
3GPP TS 24.008, not including 3GPP TS 24.008 lEI and 
3GPP TS 24.008 length indcator 



1 1 .3.21 MS Bucket Size 

This information element indicates an MS's bucket size (Bmax). The element coding is: 

Table 11.3.21: MS Bucket Size IE 





8 7 


6 


5 


4 


3 


2 


1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-4 


Bmax 



The Bmax field is coded as Bmax of BVC Bucket Size, see sub-clause 11.3.5. 

1 1 .3.22 MS Radio Access Capability 

This information element contains the capabilities of the ME. The element coding is: 

Table 11.3.22: MS Radio Access Capability IE 





8 7 6 5 4 3 2 


1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-? 


Rest of element coded as the value part defined in 
3GPP TS 24.008, not including 3GPP TS 24.008 lEI and 
3GPP TS 24.008 octet length indicator. 



11.3.23 OMC Id 

The element coding is: 



Table 11.3.23: OMC IdlE 





8 7 6 5 4 


3 


2 


1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-22 


For the OMC identity, see 3GPP TS 12.20 



11.3.24 PDU In Error 

The element coding is: 



Table 11.3.24: PDU In Error IE 





8 7 6 


5 


4 


3 


2 


1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-? 


Erroneous BSSGP PDU 
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11.3.25 PDU Lifetime 

This information element describes the PDU Lifetime for a PDU inside the BSS. The element coding is: 

Table 11.3.25: PDU Lifetime IE 





8 7 


6 


5 


4 


3 


2 


1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-4 


Delay Value 



The Delay Value field is coded as Delay Value of BVC Measurement, see sub-clause 1 1 .3.7. 
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11.3.26 PDUType 

The first octet of a BSSGP PDU shall contain the PDU type IE. The PDU type IE is one octet long. 

Table 11.3.26: PDU Types 



PDU type coding 
(Hexadecimal) 


PDU Types 




PDUs between RL and BSSGP SAPs 


xOO 


DL-UNITDATA 


x01 


UL-UNITDATA 


x02 


RA-CAPABILITY 


x03 


reserved (Note 1) 


x04 


DL-MBMS-UNITDATA 


x05 


UL-MBMS-UNITDATA 




PDUs between GMM SAPs 


x06 


PAGING-PS 


x07 


PAGING-CS 


x08 


RA-GAPABILITY-UPDATE 


x09 


RA-GAPABILITY-UPDATE-AGK 


xOa 


RADIO-STATUS 


xOb 


SUSPEND 


xOc 


SUSPEND-AGK 


xOd 


SUSPEND-NAGK 


xOe 


RESUME 


xOf 


RESUME-AGK 


x10 


RESUME-NAGK 




PDUs between NM SAPs 


x20 


BVG-BLOGK 


x21 


BVG-BLOGK-AGK 


x22 


BVG-RESET 


x23 


BVG-RESET-AGK 


x24 


BVG-UNBLOGK 


x25 


BVG-UNBLOGK-AGK 


x26 


FLOW-GONTROL-BVG 


x27 


FLOW-CONTROL-BVC-AGK 


x28 


FLOW-CONTROL-MS 


x29 


FLOW-CONTROL-MS-AGK 


x2a 


FLUSH-LL 


x2b 


FLUSH-LL-AGK 


x2c 


LLG-DISGARDED 


x2d 


FLOW-CONTROL-PFC 


x2e 


FLOW-CONTROL-PFC-AGK 


x40 


SGSN-INVOKE-TRAGE 


x41 


STATUS 


x42 


OVERLOAD 




PDUs between PFM SAPs 


0x50 


DOWNLOAD-BSS-PFG 


0x51 


GREATE-BSS-PFG 


0x52 


GREATE-BSS-PFG-AGK 


0x53 


GREATE-BSS-PFC-NAGK 


0x54 


MODIFY-BSS-PFG 


0x55 


MODIFY-BSS-PFG-AGK 


0x56 


DELETE-BSS-PFG 


0x57 


DELETE-BSS-PFG-AGK 


0x58 


DELETE-BSS-PFG-REQ 


0x59 


PS-HANDOVER-REQUIRED 


0x5a 


PS-HANDOVER-REQUIRED-AGK 


0x5b 


PS-HANDOVER-REQUIRED-NAGK 


0x5c 


PS-HANDOVER-REQUEST 


0x5d 


PS-HANDOVER-REQUEST-AGK 


0x5e 


PS-HANDOVER-REQUEST-NAGK 


0x91 


PS-HANDOVER-COMPLETE 


0x92 


PS-HANDOVER-CANGEL 
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PDU type coding 
(Hexadecimal) 


PDU Types 


0x93 


PS-HANDOVER-COMPLETE-ACK 




PDUs between LCS SAPs 


0x60 


PERFORM-LOCATION-REQUEST 


0x61 


PERFORM-LOCATION-RESPONSE 


0x62 


PERFORM-LOCATION-ABORT 


0x63 


POSITION-COMMAND 


0x64 


POSITION-RESPONSE 




PDUs between RIM SAPs 


0x70 


RAN-INFORMATION 


0x71 


RAN-INFORMATION-REQUEST 


0x72 


RAN-INFORMATION-ACK 


0x73 


RAN-INFORMATION-ERROR 


0x74 


RAN-INFORMATION-APPLICATION-ERROR 




PDUs between MBMS SAPs 


0x80 


MBMS-SESSION-START-REOUEST 


0x81 


MBMS-SESSION-START-RESPONSE 


0x82 


MBMS-SESSION-STOP-REOUEST 


0x83 


MBMS-SESSION-STOP-RESPONSE 


0x84 


MBMS-SESSION-UPDATE-REOUEST 


0x85 


MBMS-SESSION-UPDATE-RESPONSE 


RESERVED 


all values not explicitly shown are reserved for future use 


NOTE 1 : This value was allocated in an earlier version of the protocol and shall not 
be used. 



11.3.27 Priority 

This element indicates the priority of a PDU. The element coding is: 

Table 11.3.27: Priority IE 





8 7 6 5 4 3 2 1 


octet 1 


IE! 


octet 2, 2a 


Length Indicator 


octet 3 


Rest of element coded as the value part of the Priority IE defined in 
3GPP TS 48.008, not including 3GPP TS 48.008 lEI and 
3GPP TS 48.008 length indicator 



1 1 .3.28 QoS Profile 

This information element describes the QoS Profile associated with a PDU. The element coding is: 

Table 11.3.28.a: QoS Profile IE 





8 7 


6 


5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-4 


Peak bit rate 


provided by the network (note) 


octet 5 


Peak Bit Rate 
Granularity 


C/R 


T 


A 


Precedence 


NOTE: The bit rate (zero) shall mean "best effort" in this IE. 
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"Peak bit rate" is coded as shown below: 



Table 1 1 .3.28.a1 : Peak bit rate 





8 


7 


6 1 5 1 4 1 3 


2 


1 1 


octet 3 


Peak bit rate value (MSB) 


octet 4 


Peak bit rate value (LSB) 



If the Gigabit Interface feature has not been negotiated, the "Peak bit rate" field is the binary encoding of the peak bit 
rate information expressed in 100 bits/s increments, starting from x 100 bits/s until 65 535 x 100 bits/s (6 Mbps). 

If the Gigabit Interface feature has been negotiated, the "Peak bit rate" field is the binary encoding of the peak bit rate 
information expressed in increments as defined by the Peak Bit Rate Granularity field. 

"Precedence" is coded as shown below (complying with 3GPP TS 23.060). 

Table 11.3.28.b: Precedence coding 



coding 


semantic 




DL-UNITDATA 


UL-UNITDATA 


000 


High priority 


Radio priority 1 


001 


Normal priority 


Radio priority 2 


010 


Low priority 


Radio priority 3 


oil 


Reserved 


Radio priority 4 


100 


Reserved 


Radio Priority Unknown 



All values not allocated are reserved. All reserved values shall be interpreted as value 010. 
"A-bit" is coded as shown below. 

Table 11.3.28.c: "A bit" coding 



coding 


semantic 





Radio interface uses RLC/MAC ARQ functionality 


1 


Radio interface uses RLC/MAC-UNITDATA functionality 



"T-bit" is coded as shown below. 



Table 11.3.28.d: "T bit" coding 



coding 


semantic 





The SDL) contains signalling (e.g. related to GMM) 


1 


The SDL) contains data 



"C/R-bit" is coded as shown below. 



Table 11.3.28.e: "C/R bit" coding 



coding 


semantic 





The SDU contains a LLC ACK or SACK command/response 
frame type 


1 


The SDU does not contain a LLC ACK or SACK 
command/response frame type 



"Peak Bit Rate Granularity" is coded as shown below. 

Table 11.3.28.f: "Peak Bit Rate Granularity" coding 



coding 



semantic 
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00 


1 00 bits/s increments 


01 


1 000 bits/s increments 


10 


10000 bits/s increments 


11 


1 00000 bits/s increments 



This field provides the granularity to be used for deriving the peak bit rate value if the Gigabit Interface feature is 
negotiated. 

11.3.29 Radio Cause 

This information element indicates the reason for an exception condition on the radio interface. The element coding is: 

Table 11. 3.29.a: Radio Cause IE 





8 


7 


6 1 5 1 4 1 3 


2 


1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


Radio Cause value 



Table 11. 3.29.b: Radio Cause value 



radio cause value 
Hexadecimal 


Semantics of coding 


xOO 


Radio contact lost with the MS 


xOI 


Radio link quality insufficient to continue 
communication 


x02 


cell-reselection ordered 


x03 


Cell reselection prepare. See Note below. 


x04 


Cell reselection failure. See Note below. 




All values not explicitly listed are reserved. If 

received, they shall be handled as "radio contact 

lost with the MS". 


NOTE: In case the Enhanced Radio Status feature has not been 

negotiated the Radio Cause values in range of x03-x04 should 
if received be handled as "radio contact lost with the IVIS". This 
is in order to be backwards compatible with earlier releases of 
the standard. 



11.3.30 RA-Cap-UPD-Cause 

The RA-Cap-UPD-Cause indicates the success of the RA-CAP ABILITY-UPDATE procedure or the reason of the 
failure. The element coding is: 

Table 11. 3.30.a: RA-Cap-UPD-Cause IE 





8 


7 


6 1 5 1 4 1 3 1 : 


! 1 1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


RA-Cap-UPD Cause value 



Table 11.3.30.b: RA-Cap-UPD Cause value 



RA-Cap-UPD cause 

value 

Hexadecimal 



Semantics of coding 
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xOO 


OK, RA capability IE present 


x01 


TLLI unknown in SGSN 


x02 


No RA Capabilities or IIVISI available for this MS 




All values not explicitly listed are reserved. If 

received, they shall be handled as "TLLI unknown 

in SGSN". 



11.3.31 RouteingArea 

This element uniquely identifies one routeing area. The element coding is: 

Table 11.3.31: Routeing Area IE 





8 7 6 5 4 3 2 1 


octet 1 


IE! 


octet 2, 2a 


Length Indicator 


octets 3-8 


Octets 3 to 8 contain the value part (starting with octet 2) of the 

Routing Area Identification IE defined in 3GPP TS 24.008, not 

including 3GPPTS 24.008 lEI 



The coding of octet 2 is a binary number indicating the Length of the remaining element. 

11.3.32 R_default_MS 

This information element indicates the default bucket leak rate (R) to be applied to a flow control bucket for an MS. 
The element coding is: 

Table 11.3.32: R default MS IE 





8 


7 


6 1 5 1 4 1 3 


2 


1 1 


octet 1 


IE! 


octet 2, 2a 


Length Indicator 


octet 3-4 


R default MS value 



The R_default_MS value field is coded as The "R Value" of Bucket Leak Rate, see sub-clause 11.3.4. 

1 1 .3.33 Suspend Reference Number 

The Suspend Reference Number information element contains an un-formatted reference number for each 
suspend/resume transaction. The element coding is: 

Table 11.3.33: Suspend Reference Number IE 





8 


7 


1 6 1 5 1 4 1 3 1 2 


1 1 1 


octet 1 


IE! 


octet 2, 2a 


Length Indicator 


octet 3 


Suspend Reference Number 



The Suspend Reference Number is an un-formatted 8 bit field. 

11.3.34 Tag 

This information element is used to correlate request and response PDUs. The element coding is: 

Table 11.3.34: Tag IE 
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octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


Unstructured value 



1 1 .3.35 Temporary logical link Identity (TLLI) 



The element coding is: 



Table 11.3.35: TLLI IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-6 


Rest of element coded as the value part of the TLLI information 
element in 3GPP TS 44.018, not including 3GPP TS 44.018 lEI. 



1 1 .3.36 Temporary Mobile Subscriber Identity (TMSI) 



The element coding is: 



Table 11.3.36: TMSI IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-6 


Rest of element coded as the value part of the TIVISI/P-TMSI 

information element in 3GPP TS 24.008, not including 

3GPPTS 24.008 IE!. 



1 1 .3.37 Trace Reference 

This element provides a trace reference number allocated by the triggering entity. The element coding is: 

Table 11.3.37: Trace Reference IE 





8 


7 


6 


1 5 1 4 1 


3 


2 


1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-4 


Trace Reference 



11.3.38 Trace Type 

This element provides the type of trace information to be recorded. The element coding is: 

Table 11.3.38: Trace Type IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


This is coded as specified in Technical Specification 
3GPP TS 32.008. 
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1 1 .3.39 Transaction Id 

This element indicates a particular transaction within a trace. The element coding is: 

Table 11.3.39: Transaction Id IE 





8 


7 


6 


5 4 


3 


2 


1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-4 


Transaction Id 



11.3.40 Trigger Id 

This element provides the identity of the entity which initiated the trace. The element coding is: 

Table 11.3.40: Trigger Id IE 





8 7 6 5 4 3 2 


1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-22 


Entity Identity ( typically an OIVIC identity) 



1 1 .3.41 Number of octets affected 

This information element indicates, for an MS, the number of octets transferred or deleted by BSS. The element coding 
is: 

Table 1 1 .3.41 : Number of octets affected IE 





8 


7 1 6 1 5 1 4 1 3 1 2 


1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-5 


number of octets transferred or deleted 



The number of octets transferred or deleted by the BSS may be higher than the maximum Bmax value (6 553 500). 
SGSN shall handle any value higher than 6 553 500 as the value 6 553 500. 

1 1 .3.42 Packet Flow Identifier (PFI) 

This information element indicates the Packet Flow Identifier for a BSS Packet Flow Context. The element coding is: 

Table 11.3.42: Packet Flow Identifier (PFI) IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


Rest of element coded as the value part of the Packet Flow 

Identifier information element in 3GPP TS 24.008, not including 

3GPPTS 24.008 lEI 



The BSS shall not negotiate BSS PFCs for the following pre-defined PFI values: Best Effort, Signaling, SMS, and 
TOMS. 

PFIs have local significance to a mobile station. A BSS Packet Flow Context shall be uniquely identified by the PFI 
along with the IMSI or TLLI within a routeing area. 
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11. 3.42a (void) 

1 1 .3.43 Aggregate BSS QoS Profile 

This information element indicates the Aggregate BSS QoS Profile (ABQP) for a BSS Packet Flow Context or an 
MBMS Service Context. The ABQP is considered to be a single parameter with multiple data transfer attributes as 
defined in 3GPP TS 23.107. 



The element coding is: 



Table 11.3.43: Aggregate BSS QoS Profile IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-? 


Rest of element coded as the value part of the QoS information 

element in 3GPP TS 24.008, not including 3GPP TS 24.008 IE! and 

length indicator. The shorter 3-byte form of QoS information is not 

allowed in BSSGP PDUs. 



11.3.44 GPRS Timer 

The purpose of the GPRS timer information element is to specify GPRS specific timer values, e.g. the Packet Flow 
timer. 

Table 1 1 .3.44: GPRS Timer IE 





8 


1 7 1 6 


1 5 1 4 1 3 1 2 


1 1 


octet 1 


IE! 


octet 2, 2a 


Length Indicator 


octet 3 




Unit Value 


1 Timer value 


1 



Timer value: Bits 5 to 1 represent the binary coded timer value. 

Unit value: Bits 6 to 8 defines the timer value unit for the GPRS timer as follows: 



Bits 
876 

000 

001 
010 
01 1 

1 1 1 



value is incremented in multiples of 2 s 
value is incremented in multiples of 1 minute 
value is incremented in multiples of decihours 
value is incremented in multiples of 500 msec 
value indicates that the timer does not expire. 



Other values shall be interpreted as multiples of 1 minute in this version of the protocol. 

1 1 .3.45 Feature Bitmap 

The Feature bitmap information element indicates the optional features supported by the underlying NSE. The element 
coding is: 

Table 11.3.45.a: Feature Bitmap IE 
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octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


MBMS 


Enhanc 

ed 
Radio 
Status 


PFC- 
FC 


RIM 


LCS 


INR 


CBL 


RFC 



Table 11.3.45.b: "PFC bit" coding 



coding 


Semantic 





Packet Flow Context Procedures not supported 


1 


Packet Flow Context Procedures supported 



Table 11.3.45.c: "CBL bit" coding 



coding 


Semantic 





Current Bucket Level Procedures not supported 


1 


Current Bucket Level Procedures supported 



Table 11.3.45.d: "INR bit" coding 



coding 


Semantic 





Inter-NSE re-routing not supported 


1 


Inter-NSE re-routing supported 



Table 11. 3.45.e: "LCS bit" coding 



coding 


Semantic 





LCS Procedures not supported 


1 


LCS Procedures supported 



Table 11. 3.45.f: "RIM bit" coding 



coding 


Semantic 





RAN Information Management (RIM) procedures not 
supported 


1 


RAN Information Management (RIM) procedures supported 



Table 11. 3.45.g: "PFC-FC" coding 



coding 


Semantic 





PFC Flow Control Procedures not supported 


1 


PFC Flow Control Procedures supported 



Table 11. 3.45. h: "Enhanced Radio Status" coding 



coding 


Semantic 





Enhanced Radio Status Procedures not supported 


1 


Enhanced Radio Status Procedures supported 



Table 11.3.45.1: "MBMS" coding 



coding 


Semantic 





MBMS Procedures not supported 


1 


MBMS Procedures supported 
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11.3.46 Bucket Full Ratio 

This information element is used to convey the current bucket counter. It is binary encoded as follows: 
Bcurrent X (100 / Bmax)- The element coding is: 

Table 11.3.46: Bucket Full Ratio IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


Ratio of the bucket that is filled up with data 



The field ranges from zero (00000000) to two hundred and fifty five (11111111). A value of zero means that the bucket 
is empty. A value of hundred means that the bucket is exactly full, while a value of two hundred and fifty five means 
that the bucket is at least 2.55 times B^ax 

1 1 .3.47 Service UTRAN CCO 

The Service UTRAN CCO (Cell Change Order) information element indicates whether Network initiated Cell Change 
Order to UTRAN or E-UTRAN or PS Handover to UTRAN or E-UTRAN should be used for the mobile station or not, 
and it is relevant if at least one of the procedures is used: 

Table 11. 3.47.a: Service UTRAN CCO IE 





8 7 6 


5 1 4 


3 1 2 1 1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


Spare 


Service E- 

UTRAN CCO 

Value part 


Service UTRAN CCO 
Value part 



Table 11.3.47.b: Service UTRAN CCO Value part coding 



coding bits 
321 


Semantic 


000 


Network initiated cell change order to UTRAN or PS 
handover to UTRAN procedure should be performed 


001 


Network initiated cell change order to UTRAN or PS 
handover to UTRAN procedure should not be performed 


010 


Network initiated cell change order to UTRAN or PS 
handover to UTRAN procedure shall not be performed 


111 


If received, shall be interpreted as no information available 
(bits 4-5 valid) 


Other values 


If received, shall be interpreted as no information available 



Table 11. 3.47.C: Service E-UTRAN CCO Value part coding 



coding bits 
54 


Semantic 


01 


Network initiated cell change order to E-UTRAN or PS 
handover to E-UTRAN procedure should be performed 


10 


Network initiated cell change order to E-UTRAN or PS 
handover to E-UTRAN procedure should not be performed 


11 


Network initiated cell change order to E-UTRAN or PS 
handover to E-UTRAN procedure shall not be performed 


00 


If received, shall be interpreted as no information available 
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1 1 .3.48 NSEI (Network Service Entity Identifier) 

The NSEI unambiguously identifies a NSE. The element coding is: 

Table 11.3.48: NSEI IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


most significant octet of NSEI 


octet 4 


least significant octet of NSEI 



11.3.49 RRLPAPDU 

This information element conveys an embedded message associated with a higher level protocol. The element coding is: 

Table 11.3.49: RRLP APDU IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-? 


The rest of the information element contains an embedded RRLP 
message whose content and encoding are defined according to the 

3GPP TS 44.031 . The RRLP protocol is not octet aligned. 
Therefore, the unused bits in the last octet are padded with zeroes. 



11.3.50 LCSQoS 

This information element provides the LCS QoS. The element coding is: 

Table 11.3.50: LCSQOS IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-n 


Rest of element coded as the value part defined in 

3GPP TS 48.008, not including 3GPP TS 48.008 lEI and 

3GPP TS 48.008 octet length indicator 



11.3.51 LCS Client Type 

This information element provides the LCS Client Type. The element coding is: 

Table 1 1 .3.51 : LCS Client Type IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-n 


Rest of element coded as the value part defined in 

3GPP TS 49.031 , not including 3GPP TS 49.031 lEI and 

3GPP TS 49.031 octet length indicator 
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1 1 .3.52 Requested GPS Assistance Data 



This information element provides the information on which GPS Assistance Data has been requested. The element 
coding is: 

Table 11.3.52: Requested GPS Assistance Data IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-n 


Rest of element coded as the value part defined in 

3GPP TS 49.031 , not including 3GPP TS 49.031 IE! and 

3GPP TS 49.031 octet length indicator 



1 1 .3.53 Location Type 

This information element provides the Location Type. The element coding is: 

Table 11.3.53: Location Type IE 





8 7 6 5 4 3 2 1 


octet 1 


IE! 


octet 2, 2a 


Length Indicator 


octet 3-n 


Rest of element coded as the value part defined in 

3GPP TS 49.031 , not including 3GPP TS 49.031 IE! and 

3GPP TS 49.031 octet length indicator 



1 1 .3.54 Location Estimate 

This information element provides the Location Estimate. The element coding is: 

Table 11.3.54: Location Estimate IE 





8 7 6 5 4 3 2 1 


octet 1 


IE! 


octet 2, 2a 


Length Indicator 


octet 3-n 


Rest of element coded as the value part defined in 

3GPP TS 48.008, not including 3GPP TS 48.008 IE! and 

3GPP TS 48.008 octet length indicator 



11.3.55 Positioning Data 

This information element provides Positioning Data. The element coding is: 

Table 11.3.55: Positioning Data IE 





8 7 6 5 4 3 2 1 


octet 1 


IE! 


octet 2, 2a 


Length Indicator 


octet 3-n 


Rest of element coded as the value part defined in 

3GPP TS 49.031 , not including 3GPP TS 49.031 lEI and 

3GPP TS 49.031 octet length indicator 
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8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-n 


Rest of element coded as the value part defined in 

3GPP TS 49.031 , not including 3GPP TS 49.031 IE! and 

3GPP TS 49.031 octet length indicator 



1 1 .3.57 LCS Priority 

This information element provides the data/information on LCS Priority. The element coding is: 

Table 11.3.57: LCS Priority IE 





8 7 6 5 4 3 2 1 


octet 1 


IE! 


octet 2, 2a 


Length Indicator 


octet 3-n 


Rest of element coded as the value part defined in 

3GPP TS 49.031 , not including 3GPP TS 49.031 lEI and 

3GPP TS 49.031 octet length indicator 



11.3.58 LCS Cause 

This information element provides the data/information on LCS Cause. The element coding is: 

Table 11.3.58: LCS Cause IE 





8 7 6 5 4 3 2 1 


octet 1 


IE! 


octet 2, 2a 


Length Indicator 


octet 3-n 


Rest of element coded as the value part defined in 

3GPP TS 49.031 , not including 3GPP TS 49.031 IE! and 

3GPP TS 49.031 octet length indicator 



11.3.59 LCS Capability 

This information element provides the data/information on LCS Capability. The element coding is: 

Table 11.3.59: LCS Capability IE 





8 7 6 5 4 3 2 1 


octet 1 


IE! 


octet 2, 2a 


Length Indicator 


octet 3 


Rest of element coded as the value part of the PS LCS Capability 

IE defined in 3GPP TS 24.008, not including 3GPP TS 24.008 lEI 

and length indicator 



11.3.60 RRLP Flags 

This information element provides control information for the RRLP APDU. The element coding is: 

Table 11.3.60: RRLP Flags IE 
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8 


7 


6 


5 4 


3 


2 


1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


Spare 


Flagi 



The fields are coded as follows: 
Flag 1 (Octet 3, bit 1): 

Position Command (BSS to SGSN) or final response (SGSN to BSS); 

1 Not a Positioning Command or final response. 

Spare These bits shall be ignored by the receiver and set to zero by the sender. 

1 1 .3.61 RIM Application Identity 

This information element specifies the addressed application within the target BSS node. The element coding is: 

Table 11. 3.61 .a: RIM Application Identity IE 





8 


7 


6 1 5 1 4 1 3 


2 


1 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3 


RIIVI Application Identity 



RIM Application Identity is coded as shown below. 



Table 11.3.61.b: RIM Application Identity coding 



Coding 


Semantic 


0000 0000 


Reserved 


0000 0001 


Network Assisted Cell Change (NACC) 


0000 0010 


System Information 3 (SI3) 


0000 001 1 


MBMS data channel 


0000 0100 


SON Transfer 


0000 0101 


UTRA System Information (UTRA SI) 


0000 0110- 1111 1111 


Reserved 



All values not allocated are reserved. 
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1 1 .3.62 RIM Sequence Number 

This information element defines the sequence number allocated to the PDU by the source node. The element coding is: 

Table 11.3.62: RIM Sequence Number IE 





8 7 6 5 4 3 2 


1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3 


RIM Sequence Number (Higher order octet) 


Octet 4 


RIIVI Sequence Number 


Octet 5 


RIIVI Sequence Number 


Octet 6 


RIIVI Sequence Number (Lower order octet) 



11. 3.62a RIM Container 
1 1 .3.62a.O General 

The coding of the RIM Container IE value part depends on the value of the PDU type according to the following sub- 
clauses: 

1 1 .3.62a.1 RAN-INFORMATION-REQUEST RIM Container 

This information element defines the RIM container used in the RAN-INFORMATION-REQUEST PDU. The element 
coding is: 

Table 11.3.62a.1.a: RAN-INFORMATION-REQUEST RIM Container IE 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3-? 


RAN-INFORIVIATION-REOUEST RIIVI Container Contents coded as 
defined in table 11.3.62a.1b 



Table 11.3.62a.1.b: RAN-INFORMATION-REQUEST RIM Container Contents 



Information Elements 


Type / Reference 


Presence 


Format 


Length 


RIIVI Application Identity 


RIM Application Identity/1 1 .3.61 


M 


TLV 


3 


RIM Sequence Number 


RIM Sequence Number/1 1 .3.62 


M 


TLV 


6 


RIM PDU Indications 


RIM PDU Indications/11.3.65 


M 


TLV 


3 


RIM Protocol Version Number 


RIM Protocol Version 
Number/11.3.67 





TLV 


3 


Application Container (note 1) 


RAN-INFORMATION-REQUEST 
Application Container/1 1 .3.63.1 


C 


TLV 


4-? 


SON Transfer Application Identity (note 2) 


SON Transfer Application 
Identity/11.3.108 


C 


TLV 


3-m 


NOTE 1 : The presence of the Application Container depends on the value of the RIM Application Identity IE. 
NOTE 2: The SON Transfer Application Identity IE shall be present if and only if the RIM Application Identity IE is 
set to "SON Transfer". 
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1 1 .3.62a.2 RAN-INFORMATION RIM Container 

This information element defines the RIM container used in the RAN-INFORMATION PDU. The element coding is: 
Table 11. 3.62a.2.a: RAN-INFORMATION RIM Container IE 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3-? 


RAN-INFORMATION RIM Container Contents coded as defined in 
table 11. 3.62a.2b 



Table 11.3.62a.2.b: RAN-INFORMATION RIM Container Contents 



Information Elements 


Type / Reference 


Presence 


Format 


Length 


RIM Application Identity 


RIM Application Identity /1 1 .3.61 


M 


TLV 


3 


RIM Sequence Number 


RIM Sequence Number /1 1 .3.62 


M 


TLV 


6 


RIM PDU Indications 


RIM PDU Indications /11 .3.65. 


M 


TLV 


3 


RIM Protocol Version Number 


RIM Protocol Version Number/11.3.67 





TLV 


3 


Application Container (NOTE 1) 


RAN-INFORMATION Application Container 
/1 1.3.63.2 


C(Notel) 


TLV 


4-? 


Application Error Container (NOTE 1) 


Application Error Container/1 1 .3.64 


C(Notel) 


TLV 


n 


SON Transfer Application Identity 
(note 2) 


SON Transfer Application Identity/1 1 .3.1 08 


C 


TLV 


3-m 


NOTE 1 : The presence of application information depends on the value of the RIM Application Identity IE. If 

application information is mandatory either the Application Error Container \E or the Application Container 
IE is present. 

NOTE 2: The SON Transfer Application Identity IE shall be present if and only if the RIM Application Identity IE is 
set to "SON Transfer". 



1 1 .3.62a.3 RAN-INFORMATION-ACK RIM Container 

This information element defines the RIM container used in the RAN-INFORMATION-ACK PDU. The element 
coding is: 

Table 11. 3.62a.3.a: RAN-INFORMATION-ACK RIM Container IE 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3-1 6 


RAN-INFORMATION-ACK RIM Container Contents coded as 
defined in table 1 1 .3.62a.3b 



Table 11.3.62a.3.b: RAN-INFORMATION-ACK RIM Container Contents 



Information Elements 


Type / Reference 


Presence 


Format 


Length 


RIM Application Identity 


RIM Application Identity /1 1 .3.61 


M 


TLV 


3 


RIM Sequence Number 


RIM Sequence Number /1 1 .3.62 


M 


TLV 


6 


RIM Protocol Version Number 


RIM Protocol Version 
Number/11.3.67 





TLV 


4 


SON Transfer Application Identity 
(notel) 


SON Transfer Application 
Identity/11.3.108 


C 


TLV 


3-m 


NOTE 1 : The SON Transfer Application Identity IE shall be present if and only if the RIM Application 
Identity IE is set to "SON Transfer". 
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1 1 .3.62a.4 RAN-INFORMATION-ERROR RIM Container 

This information element defines the RIM container used in the RAN-INFORMATION-ERROR PDU. The element 
coding is: 

Table 11. 3.62a.4.a: RAN-INFORMATION-ERROR RIM Container IE 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3-? 


RAN-INFORMATION-ERROR RIM Container Contents coded as 
defined in table 1 1 .3.62a.4b 



Table 11. 3.62a.4.b: RAN-INFORMATION-ERROR RIM Container Contents 



Information Elements 


Type / Reference 


Presence 


Format 


Length 


RIM Application Identity 


RIM Application Identity /1 1 .3.61 


M 


TLV 


3 


RIM Cause 


Cause/1 1 .3.8 


M 


TLV 


3 


RIM Protocol Version Number 


RIM Protocol Version 
Number/11.3.67 





TLV 


3 


PDU in Error 


PDU in Error/11.3.24 


M 


TLV 


3-? 


SON Transfer Application Identity 
(note 1) 


SON Transfer Application 
Identity/11.3.108 


C 


TLV 


3-m 


NOTE 1 : The SON Transfer Application Identity IE shall be present if and only if the RIM Application 
Identity IE is set to "SON Transfer". 



1 1 .3.62a.5 RAN-INFORMATION-APPLICATION-ERROR RIM Container 

This information element defines the RIM container used in the RAN-INFORMATION-APPLICATION-ERROR 
PDU. The element coding is: 

Table 11.3.62a.5.a: RAN-INFORMATION-APPLICATION-ERROR RIM Container IE 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3-? 


RAN-INFORMATION-APPLICATION-ERROR RIM Container 
Contents coded as defined in table 1 1 .3.62a.5b 



Table 11. 3.62a.5.b: RAN-INFORMATION-APPLICATION-ERROR RIM Container Contents 



Information Elements 


Type / Reference 


Presence 


Format 


Length 


RIM Application Identity 


RIM Application Identity /1 1 .3.61 


M 


TLV 


3 


RIM Sequence Number 


RIM Sequence Number /1 1 .3.62 


M 


TLV 


6 


RIM PDU Indications 


RIM PDU Indications /1 1.3.65. 


M 


TLV 


3 


RIM Protocol Version Number 


RIM Protocol Version Number/11.3.67 





TLV 


3 


Application Error Container 


Application Error Container/11.3.64 


M 


TLV 


n 


SON Transfer Application Identity 
(note 1) 


SON Transfer Application Identity/1 1 .3.1 08 


C 


TLV 


3-m 


NOTE 1 : The SON Transfer Application Identity IE shall be present if and only if the FlIM Application Identity IE is 
set to "SON Transfer". 
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1 1 .3.63 Application Container 

1 1 .3.63.1 RAN-INFORMATION-REQUEST Application Container 



11.3.63.1.0 



General 



The coding of the Application Container value part within the RAN-INFORMATION-REQUEST RIM container 
depends on the value of the RIM Application Identity IE included into the RIM container according to the following 

sub-clauses. 



11.3.63.1.1 



RAN-INFORMATION-REQUEST Application Container for the NACC Application 



The coding of the Application Container IE within the RAN-INFORMATION-REQUEST RIM container for the 
NACC application is specified as follows: 

Table 11.3.63.1.1: RAN-INFORMATION-REQUEST Application Container coding for NACC 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3-1 


Reporting Cell Identifier 



Reporting Cell Identifier: This field is encoded as the Cell Identifier defined in sub-clause 1 1.3.9 

1 1 .3.63.1 .2 RAN-INFORMATION-REOUEST Application Container for the SI3 Application 

The coding of the Application Container IE within the RAN-INFORMATION-REQUEST RIM container for the SB 
application is specified as follows: 

Table 11.3.63.1.2: RAN-INFORMATION-REQUEST Application Container coding for SI3 





8 


7 


6 1 5 1 4 1 3 


2 


1 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3-1 


Reporting Cell Identifier 



Reporting Cell Identifier: This field is encoded as the Cell Identifier defined in sub-clause 11. 3.9 

1 1 .3.63.1 .3 RAN-INFORMATION-REOUEST Application Container for the MBMS data 

channel Application 

The coding of the Application Container IE within the RAN-INFORMATION-REQUEST RIM container for the 
MBMS data channel application is specified as follows: 

Table 11.3.63.1.3: RAN-INFORMATION-REQUEST Application Container coding for MBMS data 

channel 





8 


7 


6 1 5 1 4 1 3 


2 


1 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3-1 


Reporting Cell Identifier 



Reporting Cell Identifier: This field is encoded as the Cell Identifier defined in sub-clause 11. 3. 9 
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1 1 .3.63.1 .4 RAN-INFORMATION-REQUEST Application Container for the SON Transfer 

Application 

The coding of the Application Container IE within the RAN-INFORMATION-REQUEST RIM container for the SON 
Application is specified as follows: 

Table 11.3.63.1.4: RAN-INFORMATION-REQUEST Application Container coding for SON Transfer 





8 7 6 5 4 3 2 


1 1 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3-m 


Reporting Cell Identifier 


Octet (m+1)- 
n 


SON Transfer Request Container 



Reporting Cell Identifier: 

- If the request concerns an E-UTRAN cell, this field is encoded as the E-UTRAN CGI IE as defined in 3GPP TS 

36.413 [36]. 

If the request concerns a UTRAN cell, this field is encoded as the Source Cell Identifier IE (UTRAN Source Cell 
ID) as defined in 3GPP TS 25.413 [38]. 

If the request concerns a GERAN cell, this field is encoded as the Cell Identifier IE defined in sub-clause 1 1 .3.9. 

SON Transfer Request Container: This field is encoded as the SON Transfer Request Container IE as defined in 

3GPPTS 36.413 [36]. 

1 1 .3.63.1 .5 RAN-INFORMATION-REQUEST Application Container for the UTRA SI 

Application 

The coding of the Application Container IE within the RAN-INFORMATION-REQUEST RIM container for the 
UTRA SI application is specified as follows: 

Table 1 1 .3.63.1 .5: RAN-INFORIVIATION-REQUEST Application Container coding for UTRA SI 





8 


7 


6 1 5 1 4 1 3 


2 


1 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3-m 


Reporting Cell Identifier 



Reporting Cell Identifier: This field is encoded as the Source Cell Identifier IE (UTRAN Source Cell ID) as defined in 

3GPPTS 25.413 [38]. 
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1 1 .3.63.2 RAN-INFORMATION Application Container Unit 



11.3.63.2.0 



General 



The coding of the Application Container value part within the RAN-INFORMATION RIM container depends on the 
value of the RIM Application Identity IE included into the RIM container according to the following sub-clauses. 



11.3.63.2.1 



RAN-INFORMATION Application Container for the NACC Application 



The coding of the Application Container IE within the RAN-INFORMATION RIM container for the NACC application 
is specified as follows: 

Table 11. 3.63.2.1. a: RAN-INFORMATION Application Container coding for NACC 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3-1 


Reporting Cell Identifier 


Octet 1 1 


Number of SI/PSI 


1 Type 1 


Octet 12-n 


SI/PSI 1 



Reporting Cell Identifier: This field is encoded as the value part of the Cell Identifier IE defined in sub-clause 1 1 .3.9, 
not including lEI and Length Indicator. 

Type: This field indicates the type of SI/PSI messages provided by the reporting cell. The Type field is coded as shown 
below: 

Table 11. 3.63.2.1 .b: Type coding 



Coding 


Semantic 





SI messages as specified for BCCH (3GPP TS 44.018) follow 


1 


PSI messages as specified for PBCCH (SGPP TS 44.060) follow 



Number of SI/PSI: This field indicates the number of SI/PSI provided by the reporting cell contained in the SI/PSI 
field. This number may be zero. For system information messages with multiple instances, each instance is counted as 
one SI/PSI message. The Number of SI/PSI field is coded as shown below: 

Table 1 1 .3.63.2.1 .c: Number of SI/PSI coding 



Coding 


Semantic 


000 0000 


"SI/PSI" follows 


000 0001 


1 "SI/PSI" follow 


' 


" 


111 1111 


127 "SI/PSI" follow 



SI/PSI: This field contains a list of either system information or packet system information messages valid for the 
reporting cell. The number of (packet) system information messages is indicated in the Number of SI/PSI field specified 
above. Furthermore: 

- If the Type field indicates that "SI messages as specified for BCCH (3GPP TS 44.018) follow" then the SI/PSI 
field contains System Information message instances encoded for BCCH as specified in 3GPP TS 44.018. Each 
System Information message contains the Message type octet followed by all the lEs composing the message 
payload. Each message is 21 octets long. 

- If the Type field indicates that "PSI messages as specified for PBCCH (3GPP TS 44.060) follow" then the SI/PSI 
field contains Packet System Information message instances encoded for PBCCH as specified in 

3GPP TS 44.060. Each Packet System Information message contains the MESSAGEJTYPE field followed by the 
PSI message content. Each message is 22 octets long. 
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11.3.63.2.2 



RAN-INFORMATION Application Container for the SI3 Application 



The coding of the value part of the Application Container IE within the RAN-INFORMATION RIM container for the 
SB application is specified as follows: 

Table 11.3.63.2.2: RAN-INFORMATION Application Container coding for SI3 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3-1 


Reporting Cell Identifier 


Octet 11-31 


SI3 



Reporting Cell Identifier: The parameter is encoded as the value part of the Cell Identifier IE defined in sub-clause 
1 1.3.9, not including lEI and Length Indicator. 

SI3: contains the SYSTEM INFORMATION type 3 message encoded for BCCH as specified in 3GPP TS 44.018. It 
contains the Message type octet followed by all the lEs composing the message payload. The message is 21 octets long. 

1 1 .3.63.2.3 RAN-INFORMATION Application Container for the MBMS data channel 

Application 

The coding of the Application Container IE within the RAN-INFORMATION RIM container for the MBMS data 
channel application is specified as follows : 

Table 11. 3.63.2.3.a: RAN-INFORMATION Application Container coding for MBMS data channel 





8 7 6 5 4 3 2 


1 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3-1 


Reporting Cell Identifier 


Octet 11 -n 


IVIBMS data channel report 



Reporting Cell Identifier: This field is encoded as the value part of the Cell Identifier IE defined in sub-clause 1 1 .3.9, 
not including lEI and Length Indicator. 

MBMS data channel report: This field contains a CSNl encoded structure coded as shown below: 
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Table 11.3.63.1 .3. b: MBMS data channel report 

< MBMS data channel report struct > ::= 

{ 1 < MBMS Frequency List : < MBMS Frequency List struct > > } **0 

{1 

< MBMS p-t-m Frequency Parameters : < MBMS p-t-m Frequency Parameters struct > > 

< DOWNLINK_TIMESLOT_ALLOCATION : bit (8) > --default value common to all described bearer Id using this 
frequency allocation 

{1 

< TMGI : < TMGI IE > > - MBMS service identifier 

{ I 1 < MBMS Session Identity: bit(8) > } - session identifier of the particuiar MBMS service 

< Length of MBMS Bearer Identity : bit (3) > 

< MBMS Bearer Identity : bit (val (Length of MBMS Bearer Identity)) > 
{ |1 < EGPRS Window Size : < EGPRS Window Size IE » } 

{ I 1 < DOWNLINK_TIMESLOT_ALLOCATION : bit (8) > } - dedicated value for this bearer, overwrites the 
default value 

{ I 1 <TIMESLOT_ALLOCATION_UPLINK_FEEDBACK_CHANNEL : bit (3) > } 
{ I 1 < MBMS Radio Bearer Starting Time : < bit (1 6) > > } 

< MBMS In-band Signalling Indicator : < MBMS In-band Signalling Indicator IE » 
{ I 1 < NPM Transfer Time : bit (5) > } 

} ** - End of iist of MBMS bearer identifiers siiaring ttie same PDCI-I (frequency parameters) 

} ** -End of iist of PDCHs for this cell 

{ null I bit** = < no string > 

I 1 - Rel-7 Additions 

{1 

{ I 1 < USF : bit (3) > -choice bit indicates presence or not of parameters for the MBMS bearer 
{ I 1 < MPRACH Control Parameters : < MPRACH Control Parameters IE > > } 

} 

} ** - End of list of MBMS bearers. The list of MBMS bearers is ordered as described by the loops 

in the earlier releases part. 

] 

< padding bits > - to fill the last octet 



MBMS Frequency List: This field contains a MBMS Frequency List struct as specified in 3GPP TS 44.060 

MBMS p-t-m Frequency Parameters: This field contains a MBMS p-t-m Frequency Parameters struct as specified in 
3GPP TS 44.060 

DOWNLINK_TIMESLOT_ALLOCATION: This field contains a DOWNLINK_TIMESLOT_ALLOCATION field as 
specified in 3GPP TS 44.060 

TMGI: This field contains a TMGI IE as specified in 3GPP TS 44.060 

MBMS Session Identity: This field contains a MBMS Session Identity field as specified in 3GPP TS 44.060 

MBMS Bearer Identity: This field contains a MBMS Bearer Identity IE as specified in 3GPP TS 44.060 

EGPRS Window Size: This field contains a EGPRS Window Size IE as specified in 3GPP TS 44.060 

TIMESLOT_ALLOCATION_UPLINK_FEEDBACK_CHANNEL: This field contains a 
TIMESLOT_ALLOCATION_UPLINK_FEEDBACK_CHANNEL field as specified in 3GPP TS 44.060 

MBMS Radio Bearer Starting Time: This field is encoded as value part of the type 3 information element Starting 
r/me in 3GPPTS 44.018. 

MBMS In-band Signalling Indicator: This field contains a MBMS In-band Signalling Indicator IE as specified in 
3GPP TS 44.060. NPM Transfer Time: This field contains a NPM Transfer Time IE as specified in 3GPP TS 
44.060.USF: This field contains a USF field as specified in 3GPP TS 44.060 

MPRACH Control Parameters: This field contains a MPRACH Control Parameters IE as specified in 3GPP TS 
44.060. 
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1 1 .3.63.2.4 RAN-INFORMATION Application Container for the SON Transfer Application 

The coding of the Application Container IE within the RAN-INFORMATION RIM container for the SON Transfer 
Application is specified as follows : 

Table 11.3.63.2.4: RAN-INFORMATION Application Container coding for SON Transfer 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3 


Spare RAT discriminator 


Octet 4-m 


Reporting Cell Identifier 


Octet (m+1)- 
n 


SON Transfer Response Container 



The coding of RAT discriminator (bits 4 to 1 of octet 3) is a binary number indicating the RAT of the Reporting Cell 
Identifier. The RAT discriminator is coded as follows: 



Bits 

4321 

0000 

0001 

0010 



The reporting RAT is GERAN. 
The reporting RAT is UTRAN. 
The reporting RAT is E-UTRAN. 



All other values are reserved. 
Reporting Cell Identifier: 

If the RAT discriminator field indicates E-UTRAN, this field is encoded as the E-UTRAN CGI IE as defined in 

3GPPTS 36.413 [36]. 

If the RAT discriminator field indicates UTRAN, this field is encoded as the Source Cell Identifier IE (UTRAN 
Source Cell ID) as defined in 3GPP TS 25.413 [38]. 

If the RAT discriminator field indicates GERAN, this field is encoded as the value part of the Cell Identifier IE 
defined in sub-clause 11. 3. 9, not including lEI and Length Indicator. 

SON Transfer Response Container: This field is encoded as the SON Transfer Response Container IE as defined in 
3GPPTS 36.413 [36]. 



11.3.63.2.5 



RAN-INFORMATION Application Container for the UTRA SI Application 



The coding of the Application Container IE within the RAN-INFORMATION RIM container for the UTRA SI 
application is specified as follows: 

Table 11.3.63.2.5: RAN-INFORMATION Application Container coding for UTRA SI 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3-m 


Reporting Cell Identifier 


Octet (m+1)-n 


UTRA SI Container 



Reporting Cell Identifier: This field is encoded as the Source Cell Identifier IE (UTRAN Source Cell ID) as defined in 

3GPPTS 25.413 [38]. 

UTRA SI Container: This field contains System Information Container valid for the reporting cell encoded as defined 

in TS 25.331 [42]. 
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1 1 .3.64 Application Error Container 

1 1 .3.64.1 Application Error Container layout for the NACC application 

The coding of the Application Error Container IE for the NACC appHcation is specified as follows: 
Table 11. 3.64.1. a: Application Error Container coding for NACC 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3 


NACC Cause 


Octet 4-n 


Erroneous Application Container including lEI and LI 



NACC Cause: This field indicates the cause why the Application Error Container IE is sent. The NACC Cause field is 
coded as shown below: 

Table 11. 3.64.1 .b: NACC Cause coding 



Coding 


Semantic 


0000 0000 


Other unspecified error 


0000 0001 


Syntax error in the Application Container 


0000 0010 


Reporting Cell Identifier does not match with the Destination Cell 
Identifier or with the Source Cell Identifier. 


0000 001 1 


SI/PSI type error 


0000 0100 


Inconsistent length of a SI/PSI message 


0000 0101 


Inconsistent set of messages 


other 
values 


reserved 



"Other unspecified error": none of the error description below fits with the detected error 

"Syntax error in tfie Appiication Container": the Application Container IE is syntactically incorrect 

"Reporting Ceii Identifier does not matcli witli tlie Destination Cell Identifier or witli tlie Source Cell 
Identifier": the Reporting Cell Identifier in the Application Container IE does not match with the Destination Cell 
Identifier IE value (in the case of a RAN-INFORMATION-REQUEST PDU) or with the Source Cell Identifier IE value 
(in the case of a RAN-INFORMATION PDU) of the RIM PDU 

"SI/PSI type error": the Application Container IE contains system information messages instead of packet system 
information messages or conversely 

"Inconsistent lengtli of a SI/PSI message": the length contained in one SI/PSI message does not fit with the content 
of the message 

"Inconsistent set of messages": the status of the change marks reported in the (packet) system information message set 
is inconsistent 

Erroneous Application Container: this field contains the erroneous Application Container IE 

1 1 .3.64.2 Application Error Container for the SI3 application 

The coding of the Application Error Container IE for the SI3 application is specified as follows: 
Table 11.3.64.2.a: Application Error Container coding for SI3 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3 


SI3 Cause 


Octet 4-n 


Erroneous Application Container including lEI and LI 
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813 Cause: This field indicates the cause why the Application Error Container IE is sent. The SB Cause field is coded 
as shown below: 

Table 11.3.64.2.b: SIS Cause coding 



Coding 


Semantic 


0000 0000 


Other unspecified error 


0000 0001 


Syntax error in the Application Container 


0000 0010 


Reporting Cell Identifier does not match with the Destination Cell 
Identifier or with the Source Cell Identifier. 


0000 001 1 


Inconsistent length of a SIS message 


other 
values 


Reserved 



"Other unspecifled error": None of the error description below fits with the detected error; 

"Syntax error in the Application Container": the Error Application Container is syntactically incorrect; 

"Reporting Cell Id does not match with the Destination Cell Identifier or with the Source Cell Identifier": the 

Reporting Cell Identifier in the Application Container IE does not match with the Destination Cell Identifier IE value 
(in the case of a RAN-INFORMATION-REQUEST PDU) or with the Source Cell Identifier IE value (in the case of a 
RAN-INFORMATION PDU) of the RIM PDU; 

"Inconsistent length of a SIS message": the length contained in the SB message does not fit with the content of the 

message; 

Erroneous Application Container: This field contains the erroneous Application Container IE. 

1 1 .3.64.3 Application Error Container for the MBMS data channel application 

The coding of the Application Error Container IE for the MBMS data channel application is specified as follows: 
Table 11.3.64.3.a: Application Error Container coding for MBMS data channnel 





8 7 6 5 4 3 2 1 


Octet 1 


IE! 


Octet 2, 2a 


Length Indicator 


Octet 3 


IVIBMS data channel Cause 


Octet 4-n 


Erroneous Application Container including lEI and LI 



MBMS data channel Cause: This field indicates the cause why the Application Error Container IE is sent. The MBMS 
data channel Cause" field is coded as shown below: 

Table 11.3.64.3.b: MBMS DATA CHANNEL Cause coding 



Coding 


Semantic 


0000 0000 


Other unspecified error 


0000 0001 


Syntax error in the Application Container 


0000 0010 


Reporting Cell Identifier does not match with the Destination Cell 
Identifier or with the Source Cell Identifier. 


0000 001 1 


RAN-INFORMATION/lnitial Multiple Report or RAN- 

INFORMATION/Single Report PDU exceeds the maximum 

supported length 


0000 0100 


Inconsistent IVIBMS data channel description 


other 
values 


reserved 



"Other unspecified error": None of the error description below fits with the detected error. 

"Syntax error in the Application Container": the Application Container IE is syntactically incorrect. 
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"Reporting Cell Id does not match with the Destination Cell Identifier or Source Cell Identifier respectively": 

the Reporting Cell Identifier in the Application Container IE does not match with the Destination Cell Identifier IE 
value (in the case of a RAN-INFORMATION-REQUEST PDU) or with the Source Cell Identifier IE value (in the case 
of a RAN-INFORMATION PDU) of the RIM header. 

"RAN-INFORMATION/Initial Multiple Report or RAN-INFORMATION/Single Report PDU exceeds the 
maximum supported length": the RAN-INFORMATION/Initial Multiple Report PDU exceeds the maximum length 
supported by the system. 

"Inconsistent MBMS data channel description": failure in a MBMS data channel description. 

Erroneous Application Container: This field contains the erroneous Application Container IE . 

1 1 .3.64.4 Application Error Container for the SON Transfer Application 

The coding of the Application Error Container IE for the SON Transfer Application is specified as follows: 
Table 11.3.64.4: Application Error Container coding for SON Transfer 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3-m 


SON Transfer Cause 


Octet (m+1)- 
n 


Erroneous Application Container including IE! and LI 



SON Transfer Cause: This field indicates the cause why the Application Error Container IE is sent. The "SON 
Transfer Cause" field is encoded as the SON Transfer Cause IE as defined in 3GPP TS 36.413 [36]. 

1 1 .3.64.5 Application Error Container for the UTRA SI Application 

The coding of the Application Error Container IE for the UTRA SI Application is specified as follows: 
Table 11.3.64.5.a: Application Error Container coding for UTRA SI 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3 


UTRA SI Cause 


Octet 4-n 


Erroneous Application Container including lEI and LI 



UTRA SI Cause: This field indicates the cause why the Application Error Container IE is sent. The UTRA SI Cause 
field is coded as shown below: 

Table 11.3.64.5.b: UTRA SI Cause coding 



Coding 


Semantic 


0000 0000 


Unspecified 


0000 0001 


Syntax Error in the Application Container 


0000 0010 


Inconsistent Reporting Cell Identifier 


other 
values 


Reserved 



"Unspecified": Sent when none of the above cause values applies. 

"Syntax Error in the Application Container": The Application Container IE is syntactically incorrect. 

"Inconsistent Reporting Cell Identifier": The cell identified by Reporting Cell Identifier in the Application Container 
IE is unknown in the RNC identified by the Destination Cell Identifier IE value in the RAN-INFORMATION- 
REQUEST PDU. 
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Erroneous Application Container: This field contains the erroneous Application Container IE. 

1 1 .3.65 RIM PDU Indications 
11.3.65.0 General 

This information element contains various indications related to a RAN-INFORMATION-REQUEST PDU, RAN- 
INFORMATION PDU or RAN-INFORMATION- APPLICATION-ERROR PDU. 

The element coding is: 

Table 11.3.65.a: RIM PDU Indications IE 





8 7 6 


1 5 1 4 1 3 1 2 


1 1 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3 


Reserved 


PDU Type Extension 


1 ACK 1 



ACK: this field indicates whether the source side is requesting a RAN-INFORMATION- ACK PDU as response to a 
RAN-INFORMATION or to a RAN-INFORMATION- APPLICATION-ERROR PDU. This field is coded as shown 
below. 

Table 11. 3.65.b: ACK coding 



Coding 


Semantic 





No ACK requested 


1 


ACK requested 



PDU Type Extension: This field specifies the type extension of the PDU. The defined values depend on the PDU type. 

1 1 .3.65.1 RAN-INFORMATION-REQUEST RIM PDU Indications 

The ACK field is not used and shall be considered as spare. 

The following values of the PDU Type Extension field are defined: 

Table 11.3.65.1: RAN-INFORMATION-REQUEST PDU Type Extension coding 



Coding 


Semantic 


000 


RAN-INFORMATION-REQUEST/Stop PDU 


001 


RAN-INFORMATION-REQUEST/Single Report PDU 


010 


RAN-INFORMATION-REQUEST/Multiple Report PDU 


oil 


Reserved 


100 


Reserved 


101 


Reserved 


110 


Reserved 


111 


Reserved 



1 1 .3.65.2 RAN-INFORMATION RIM PDU Indications 

The AC/r field is defined as specified in sub-clause 11.3.65.0. 
The following values of the PDU Type Extension field are defined: 
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Table 11.3.65.2: RAN-INFORMATION PDU Type Extension coding 



Coding 


Semantic 


000 


RAN-INFORMATION/Stop PDU 


001 


RAN-INFORMATION/Single Report PDU 


010 


RAN-INFORMATION/lnitial Multiple Report PDU 


oil 


RAN-INFORMATION/Multiple Report PDU 


100 


RAN-INFORMATION/End PDU 


101 


Reserved 


110 


Reserved 


111 


Reserved 



1 1 .3.65.3 RAN-INFORMATION-APPLICATION-ERROR RIM PDU Indications 

The AC/r field is defined as specified in sub-clause 11.3.65.0. 

The PDU Type Extension field is not used and shall be considered as spare. 

11.3.66 (void) 

1 1 .3.67 RIM Protocol Version Number 

This information element defines which version number of the RIM protocol is in use in the PDU. The element coding 
is: 

Table 11. 3.67.a: RIM Protocol Version Number IE 





8 


7 


1 6 1 5 1 4 1 3 1 


2 


1 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3 


RIM Protocol Version Number 



RIM Protocol Version Number is coded as follows: 

Table 11.3.67.b: RIIVI Protocol Version Number IE coding 



Coding 


Semantic 


0000 0000 


Reserved 


0000 0001 


Version 1 


Other values 


Reserved 



If this Information Element is omitted the value "Version 1" should be assumed. 
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1 1 .3.68 PFC Flow Control parameters 

This information element contains the flow control parameters for one or more PFC(s) of a certain MS. The element 
coding is: 

Table 11. 3.68.a: PFC Flow Control parameters IE 





8 7 6 5 4 3 


2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


Number of PFCs 


Octet 4 


PF1(1) 


Octet 5-6 


Bmax PFC(1) 


Octet 7-8 


R PFC(1) 


Octet 9 


B PFC(1) 


Octet ? 


PFI (2) 


Octet ?-? 


Bmax PFC (2) 


Octet ?-? 


R PFC (2) 


Octet ? 


B PFC (2) 


" 


" 


Octet ? 


PFI (n) 


Octet ?-? 


Bmax PFC (n) 


Octet ?-? 


R PFC(n) 


Octet ? 


B PFC(n) 



Number of PFCs: Number of PFCs for which flow control parameters are provided. For each of those PFCs follows its 
identifier and the value of the flow control parameters. The "Number of PFCs"parameter is coded as shown below: 

Table 11. 3.68.b: Number of PFCs 



Coding 


Semantic 


0000 0000 


OPFC 


0000 0001 


1 PFC 






0000 1011 


1 1 PFCs 


0000 1100 


Reserved 


1 


" 


1111 1111 


Reserved 



PFI: Packet Flow Identifier. Coded as the value part of the Packet Flow Identifier information element in 
3GPP TS 24.008, not including 3GPP TS 24.008 lEI. 

Bmax_PFC: Bucket size of the PFC. Coded like the value part of BVC Bucket Size, see sub-clause 11.3.5. 

R_PFC: Bucket Leak Rate of the PFC. Coded as the value part of Bucket Leak Rate (R), see sub-clause 11 .3.4. 

B_PFC: Bucket Full Ratio of the PFC. This field is only present if the Current Bucket Level (CBL) feature is 
negotiated. Otherwise, the flow control parameters for the next PFC, if any, are provided instead. This field if coded as 
the value part of the Bucket Full Ratio, see sub-clause 11.3.46. 

11.3.69 Global CN-ld 

The Global CN-Id consists of a PLMN-Id and a CN-Id, see 3GPP TS 23.003. The value part of the Global CN-Id is 
coded as defined in 3GPP TS 29.018. The CN-Id is an integer defined by O&M. The element coding is: 
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Table 11.3.69: Global CN-ld IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-7 


Coded as octets 3 to 7 of the Global CN-ld IE, defined in 
3GPPTS29.018 



1 1 .3.70 RIM Routing Information 

This information element uniquely identifies either a cell within a GERAN BSS, a UTRAN RNC or an E-UTRAN 
eNodeB. The element coding is: 

Table 11.3.70: RIM Routing Information IE 





8 7 6 


1 5 1 4 1 3 1 2 1 1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


Spare 


RIM Routing Address 
discriminator 


octet 4-n 


RIM Routing Address 



The coding of RIM Routing Address discriminator (bits 4 to 1 of octet 3) is a binary number indicating which type of 
address is provided in octet 4-n. The RIM Routing Address discriminator is coded as follows: 



Bits 

4321 

0000 

0001 

0010 



A Cell Identifier is used to identify a GERAN cell. 

An RNC identifier is used to identify a UTRAN RNC. 

An eNB identifier is used to identify an E-UTRAN eNodeB or HeNB 



All other values are reserved. 

The coding of octet 4-n depends on the RIM Routing Address discriminator (octet 3) as it is specified below. 

RIM Routing Address discriminator = 0000: 

The RIM Routing Address field contains a Cell Identifier and is coded as the value part (octet 3 to octet 10) of the Cell 
Identifier information element specified in sub-clause 11. 3. 9. 

RIM Routing Address discriminator = 0001: 

The RIM Routing Address field contains an RNC identifier and is coded as follows: 



8 



Octets 4 to 9 contain the value part (starting with octet 

2) of the Routing Area Identification IE defined in 
3GPP TS 24.008. not including 3GPP TS 24.008 lEI 



RNC-ID (or Extended RNC-ID) 



RNC-ID (or Extended RNC-ID) (continued) 



octets 4-9 



octet 1 
octet 1 1 



The octets 10-1 1 contain the RNC-ID (0..4095) or the Extended RNC-ID (4096..65535) - see 3GPP TS 25.413: 

The least significant bit of RNC-ID is octet 11 bit 1 and most significant bit is octet 10 bit 4. In the octet 10 bits 
5-8 are set to "0000". 

The least significant bit of Extended RNC-ID is octet 1 1 bit 1 and most significant bit is octet 10 bit 8. 

RIM Routing Address discriminator = 0010: 
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The RIM Routing Address field contains an eNB identifier and is coded as follows: 



8 


7 


6 


5 


4 


3 


2 


1 


Octets 4 to 8 contain the value part (starting with octet 


2) of the Tracking Area Identity IE defined in 3GPP 


TS 24.301 [37], not including 3GPP TS 24.301 lEI 


[37] 


Global eNB ID 



octet 4-8 



octet 9-n 



Octets 9-n contain the Global eNB ID (see 3GPP TS 36.413 [36] sub-clause 9.3.4, Global -ENB-ID Sequence) of the 
eNodeB. 

1 1 .3.71 MBMS Session Identity 

The MBMS Session Identity is an identification of the MBMS Session as defined in 3GPP TS 23.246 [32]. The element 
coding is: 

Table 11.3.71: MBMS Session Identity IE 





8 7 6 5 4 3 2 1 


octet 1 


IE! 


octet 2, 2a 


Length Indicator 


octet 3 


MBMS-Session-ldentity AVP encoded as in 3GPP TS 29.061 [31], 
excluding AVP Header fields as defined in IETF RFC 3588 [33]. 



1 1 .3.72 MBMS Session Duration 

The MBMS Session Duration defines the (remaining) duration of the MBMS Session as defined in 3GPP TS 23.246 
[32]. The element coding is: 

Table 11.3.72: MBMS Session Duration IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-m 


IVIBMS-Session-Duration AVP encoded as in 3GPP TS 29.061 [31], 
excluding AVP Header fields as defined in IETF RFC 3588 [33]. 



1 1 .3.73 MBMS Service Area Identity List 

The MBMS Service Area Identity List identifies the Service Areas Identities for the Service Areas where the MBMS 
Session shall be active as defined in 3GPP TS 29.061. The element coding is: 

Table 11.3.73: MBMS Service Area Identity List IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 - 
514 


MBMS-Service-Area AVP encoded as in 3GPP TS 29.061 , 
excluding AVP Header fields (as defined in IETF RFC 3588 [33]). 
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11.3.74 MBMS Response 

The MBMS Response identifies the Cause Values from the BSS regarding MBMS. 

Table 11. 3.74.a: MBMS Response IE 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3 


Spare Spare Spare Spare Cause Value 



Table 11.3.74.b: Cause Value 



(octet 3) 
Bits 8 7 6 5 



Spare 



Bits 

4321 

0000 

0001 

0010 

0011 

100 

0101 

110 

1111 



Acknowledge 

Acknowledge, initiate data transfer 

Acknowledge, data transfer initiated from other SGSN 

Reject - Congestion 

Reject - None of the listed IVIBMS Service Areas are supported by BSS 

Reject - MBMS Service Context is released due to interrupted data flow 

Unspecified in this version of the protocol 



11.3.75 MBMS Routing Area List 

The MBMS Routing Area List identifies each Routing Area that contains at least one PMM-IDLE MS that has activated 
the MBMS bearer service. The list may be empty. 

Table 11. 3.75.a: MBMS Routing Area List IE 





8 7 6 5 4 3 2 1 


octet 1 


IE! 


octet 2, 2a 


Length Indicator 


octet 3 


Number of Routing Area 
Identifications 


Spare 


Spare 


Spare 


Spare 


octet 4-11 


Routing Area Identification 1 


octet 12- 19 


Routing Area Identification 2 


octet 20 - 27 


Routing Area Identification 3 


octet 28 - 35 


Routing Area Identification 4 


octet 36 - 43 


Routing Area Identification 5 


octet 44-51 


Routing Area Identification 6 


octet 52 - 59 


Routing Area Identification 7 


octet 60 - 67 


Routing Area Identification 8 


octet 68 - 75 


Routing Area Identification 9 


octet 76 - 83 


Routing Area Identification 10 


octet 84-91 


Routing Area Identification 1 1 


octet 92 - 99 


Routing Area Identification 12 


octet 1 00 - 1 07 


Routing Area Identification 13 


octet 108 -115 


Routing Area Identification 14 
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Table 11.3.75.b: MBMS Routing Area List information element details 



Number of Routing Areas (octet 3) 
8765 

Notification shall not be sent to any Routing Areas in the BSS 
1 " 1 " Routing Area Identities 



1110 "14" Routing Area Identities 

1111 Notification shall be sent in all Routing Areas in the BSS 



4 3 21 (octet 3) 
Spare 



Routing Area Identification i 7 octets (octet 4, 12, 20, 28, 36, 44, 52, 60, 68, 76, 

84, 92, 100 and 108) 

The element is coded as the Routing Area Identification information element in 

3GPP TS 24.008, not including 3GPP TS 24.008 lEI and 3GPP TS 24.008 length 

indicator. 



1 1 .3.76 MBMS Session Information 

The MBMS Session Information carries information about the MBMS Session from the SGSN to the BSS. 

Table 11.3.76.a: MBMS Session Information IE 





8 


7 


6 5 4 3 


2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


Spare 


Spare 


Spare Spare Spare Spare 


Spare BC/MC 



Table 11.3.76.b: MBMS Session Information information element details 



BC/MC (octet 3) 

This field indicates wheter it is a Broadcast or an Multicast MBMS Session. 

Bit 

1 

Broadcast Session 

1 Multicast Session 

8 7 6 5 4 3 2 (octet 3) 
Spare 



1 1 .3.77 TMGI (Temporary Mobile Group Identity) 

The purpose of TMGI is for group paging in MBMS as defined in 3GPP TS 24.008. 

Table 11.3.77: TMGI IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2,2a 


Length Indicator 


octet 3-8 


Rest of element coded as in 3GPP TS 24.008, not including 3GPP 
TS 24.008 lEI and 3GPP TS 24.008 length indicator. 
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11.3.78 MBMS Stop Cause 

The MBMS Stop Cause identifies the Cause Values for stopping an MBMS Session. 

Table 11. 3.74.a: MBMS Stop Cause IE 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3 


Spare Spare Spare Spare Cause Value 



Table 11.3.74.b: Cause Value 



(octet 3) 




Bits 8 7 6 5 Spare 


Bits 




4321 




0000 


IVIBMS Session terminated by upstream node 


0001 


MBMS Session terminated by SGSN 


0010 






Unspecified in this version of the protocol 


1111 





1 1 .3.79 Source BSS to Target BSS Transparent Container 

This information element contains the information needed in the Target BSS to execute a PS Handover. 
The element coding is: 

Table 11.3.79.a: Source BSS to Target BSS Transparent Container coding 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3-? 


Source BSS to Target BSS Transparent Container Contents coded 
as defined in table 1 1 .3.79.b 



Table 11. 3.79. b: Source BSS to Target BSS Transparent Container Contents 



Information Elements 


Type / Reference 


Presence 


Format 


Length 


MS Radio Access Capability 


MS Radio Access Capability/1 1 .3.22 


M 


TLV 


1-1 


Inter RAT Handover Info 


Inter RAT Handover Info/1 1 .3.94 


0(note 1) 


TLV 


3-? 


Page Mode 


Page Mode/11.3.88 


(note 2, 
note 3) 


TLV 


3 


Container ID 


Container ID/11.3.89 


(note 2) 


TLV 


3 


Global TFI 


Global TFI/1 1.3.90 


(note 2, 
note 3) 


TLV 


3 


PS Handover Indications 


PS Handover Indications/1 1 .3.95a 





TLV 


3 


CS Indication 


CS Indication/11.3.98 


(note 3) 


TLV 


3 


E-UTRAN Inter RAT Handover Info 


E-UTRAN Inter RAT Handover 
Info/11.3.104 


O(notel) 


TLV 


3-? 


IRAT Measurement Configuration 


IRAT Measurement 
Configuration/11.3.115 




(note 4) 


TLV 


3-? 


N0TE1 : This information element shall be present if available in the source BSS. 
N0TE2: This information element shall be present in case of PS Handover from A/Gb mode. 
N0TE3: This information element shall be present in case of DTM Handover from A/Gb mode. 
N0TE4: This information element may be present in case of PS Handover from E-UTRAN (see 
3GPPTS36.413[361) 
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1 1 .3.80 Target BSS to Source BSS Transparent Container 

This information element contains the information needed in the Source BSS to execute a PS Handover. 
The element coding is: 

Table 11.3.80.a: Target BSS to Source BSS Transparent Container coding 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2 2a 


Length Indicator 


Octet 3-? 


Target BSS to Source BSS Transparent Container Contents coded 
as defined in table 11. 3.80.b 



Table 11. 3.80. b: Target BSS to Source BSS Transparent Container Contents 



Information Elements 


Type / Reference 


Presence 


Format 


Length 


PS Handover Command 


PS Handover Command/1 1 .3.95 


(Note 2) 


TLV 


4-? 


SI/PSI Container 


SI/PSI Container/11 .3.95b 


(Motel) 


TLV 


3-? 


DTIVI Handover Command 


DTM Handover Command/1 1 .3.97 


(Note 2) 


TLV 


22-? 


NOTE 1 : This information element shall be included when requested in the PS-HANDOVER- 
REQUEST PDU. 
NOTE 2: Only one of these information elements shall be included. 



1 1 .3.81 NAS container for PS Handover 

This information element contains the NAS container for PS Handover. The value part of this IE is to be included in the 
PS Handover Command message within the Target BSS to Source BSS Transparent Container IE. 



The element coding is: 



Table 11.3.81 : NAS container for PS Handover coding 





8 7 6 5 4 3 2 1 


Octet 1 


IE! 


Octet 2, 2a 


Length Indicator 


Octets 3-? 


NAS container for PS HO coded as defined in 3GPP TS 24.008 
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1 1 .3.82 PFCs to be set-up list 



This information element contains the Packet Flow Context parameters for one or more PFC(s), that the SGSN requests 
the target BSS to set-up. 



The element coding is: 



Table 11. 3.82.a: PFCs to be set-up list IE 





8 7 6 5 4 3 2 


1 1 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3 


Number of PFCs 


Octet 4-6 


PF1(1) 


Octet 7-9 


PFT(1) 


Octet 10-? 


ABOPd) 


Octet ?-? 


Allocation/Retention Priority (1) 


Octet ?-? 


110(1) 


Octet ?-? 


PFI (2) 


Octet ?-? 


PFT (2) 


Octet ?-? 


ABQP (2) 


Octet ?-? 


Allocation/Retention Priority (2) 


Octet ?-? 


110(2) 


" 


" 


Octet ?-? 


PFI (n) 


Octet ?-? 


PFT (n) 


Octet ?-? 


ABQP (n) 


Octet ?-? 


Allocation/Retention Priority (n) 


Octet ?-? 


T10(n) 



Number of PFCs: Number of PFCs for which packet flow context parameters are provided. For each of those PFCs 
follows its identifier and the packet flow context parameters. The "Number of PFCs" parameter is coded as shown 
below: 

Table 11. 3.82.b: Number of PFCs 



Coding 


Semantic 


0000 0000 


Reserved 


0000 0001 


1 PFC 






0000 1011 


1 1 PFCs 


0000 1100 


Reserved 


' 


" 


1111 1111 


Reserved 



PFI: Packet Flow Identifier. Coded as the Packet Flow Identifier information element, see sub-clause 1 1.3.42 

PFT: Packet Flow Timer. Coded as the GPRS Timer information element, see sub-clause 11. 3. 44. 

ABQP: Aggregate BSS QoS Profile. Coded as the Aggregate BSS QoS Profile information element, see sub-clause 
11.3.43. 

Allocation/Retention Priority: Allocation Retention Priority. Coded as the Priority information element, see sub- 
clause 1 1.3.27. This information element is optionally included. 

TIO: TIO. Coded as the GPRS Timer information element, see sub-clause 1 1.3.44. This information element shall be 
present for a PFC if the Allocation/Retention Priority is present and if queuing is allowed for the PFC. 
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1 1 .3.83 List of set-up PFCs 

This information element contains the Packet Flow Identifiers of the PFCs that were successfully allocated in the target 
system during a PS handover. The element coding is: 

Table 11.3.83.a: List of set-up PFCs IE 





8 7 6 5 4 3 


2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


Number of PFCs 


Octet 4 


PFI(1) 


Octet 5 


PFI (2) 


" 


" 


Octet ? 


PFI (n) 



Number of PFCs: Number of PFCs for which corresponding Packet Flow Identifiers are provided. The "Number of 
PFCs" parameter is coded as shown below: 

Table 11. 3.83.b: Number of PFCs 



Coding 


Semantic 


0000 0000 


OPFC 


0000 0001 


1 PFC 






0000 1011 


1 1 PFCs 


0000 1100 


Reserved 


' 


" 


1111 1111 


Reserved 



PFI: Packet Flow Identifier. Coded as the value part of the Packet Flow Identifier information element in 
3GPP TS 24.008, not including 3GPP TS 24.008 lEI. 

1 1 .3.84 Extended Feature Bitmap 

The Extended Feature bitmap information element indicates the optional features supported by the underlying NSE. The 
element coding is: 

Table 11.3.84.a: Extended Feature Bitmap IE 





8 


7 


6|5|4|3|2|1| 


octet 1 


lEI 


octet 2, 2a 


Lengtii Indicator 


octet 3 


Spare 


Spare 


Spare 


Spare 


Spare 


MOCN 


Gigabit 

Interfac 

e 


PS 

Handov 

er 



Table 11. 3.84.b: "PS Handover" coding 



coding 


Semantic 





PS Handover not supported 


1 


PS Handover supported 



Table 11.3.84.c: "Gigabit Interface" coding 



coding 


Semantic 





Gigabit Interface not supported 


1 


Gigabit Interface supported 
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Table 11.3.84.d: "Multi Operator Core Network' coding 



coding 


Semantic 





Multi Operator Core Network not supported 


1 


Multi Operator Core Network supported 



1 1 .3.85 Source to Target Transparent Container 

This information element contains the information needed in the target RAN node to execute a inter-RAT PS or DTM 
Handover. 



The element coding is: 



Table 1 1 .3.85: Source to Target Transparent Container coding 





8 7 6 5 4 3 2 1 


Octet 1 


IE! 


Octet 2, 2a 


Length Indicator 


Octets 3-? 


Source to Target Transparent Container content coded as 
specified in 3GPP TS 25.413 or 3GPP TS 36.413. 



In inter-RAT handovers to lu mode this IE includes the Source RNC to Target RNC Transparent container. The Source 
RNC to Target RNC Transparent Container content structure and encoding is defined in relevant RANAP specification 
3GPP TS 25.413, excluding RANAP tag. 

In inter-RAT handover to E-UTRAN this IE includes the Source eNB to Target eNB Transparent container. The Source 
eNB to Target eNB Transparent Container content structure and encoding is defined in 3GPP TS 36.413. 

1 1 .3.86 Target to Source Transparent Container 

This information element contains the information needed in the Source BSS to execute a inter-RAT PS Handover. 
The element coding is: 

Table 11.3.86: Target to Source Transparent Container coding 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octets 3-? 


Rest of element coded as either a complete Handover to UTRAN 

Command radio interface message (as defined in 3GPP TS 

25.331) or a complete Radio Bearer Reconfiguration radio 

interface message (as defined in 3GPP TS 44.118) or a 

HandoverCommand message that consists only of the DL-DCCH- 

Message including a complete RRCConnectionReconfiguration 

radio interface message (as defined in 3GPP TS 36.331) 



11.3.87 RNC Identifier 

This information element contains the identifier of the RNC in case of PS Handover to UTRAN or the Corresponding 
RNC -ID of the eNB in case of PS handover to E-UTRAN as specified in 3GPP TS 25.413. 
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The element coding is: 



Table 11.3.87: RNC Identifier coding 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octets 3-8 


Octets 3 to 8 contain the value part (starting with octet 2) of the 

Routing Area Identification IE defined in 3GPP TS 24.008, not 

including 3GPP TS 24.008 lEI 


Octet 9 


RNC ID (or Extended RNC-ID or Corresponding RNC-ID) 


Octet 10 


RNC ID (or Extended RNC-ID or Corresponding RNC-ID) 
(continued) 



RNC ID (or Extended RNC-ID or Corresponding RNC-ID): The octets 9-10 contain the RNC-ID (0..4095) or the 
Corresponding RNC-ID (0..4095) or the Extended RNC-ID (4096..65535) - see 3GPP TS 25.413: 

The least significant bit of RNC-ID is octet 10 bit 1 and most significant bit is octet 9 bit 4. In the octet 9 bits 5- 
are set to "0000". 

The least significant bit of Extended RNC-ID is octet 10 bit 1 and most significant bit is octet 9 bit 8. 

For detailed definition of the RNC-Id see 3GPP TS 23.003. 

11.3.88 Page Mode 

This information element contains the Page Mode to be used by the MS. 
The element coding is: 

Table 11.3.88: Page Mode coding 





8 7 6 5 4 3 


2 1 1 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3 


Reserved 


PAGE_MODE 

coded as 

specified in 

3GPP TS 

44.060 



11.3.89 Container ID 

This information element contains the identity of the neighbour cell system information container previously sent to the 
MS. 



The element coding is: 



Table 11.3.89: Container ID coding 





8 7 6 5 4 3 


2 1 1 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3 


Reserved 


Container ID 
coded as 

specified in 

3GPP TS 

44.060 
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11.3.90 Global TFI 

This information element contains the TFI of the mobile station's downlink or uplink TBF. 
The element coding is: 

Table 11.3.90: Global TFI coding 





8 7 


|6|5|4|3|2|1| 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3 


Reserved 


Global TFI coded as specified in 3GPP TS 44.060 



11.3.91 IMEI 

This information element contains the International Mobile Station Equipment Identity (see 3GPP TS 23.003). The 
element coding is: 

Table 11.3.91: IMEI IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-10 


Octets 3-10 contain the IIVIEI coded as the value part of the Mobile 

Identity IE defined in 3GPP TS 24.008 

(N0TE1) 


NOTE 1 : The Type of identity f\e\6 in the Mobile Identity IE shall be ignored by 
the receiver. 



1 1 .3.92 Time to MBMS Data Transfer 

The Time to MBMS Data Transfer denotes the time occurring between the transmission of the MBMS-SESSION- 
START-REQUEST PDU or the MBMS-SESSION-UPDATE-REQUEST PDU to the BSS and the actual start of the 
data transfer at the BM-SC. 

Table 11.3.92.a: Time to MBMS Data Transfer IE 





8 


7 1 6 1 5 1 4 1 3 1 2 


1 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3 


Time to MBMS Data Transfer Value Part 



Table 11. 3.92. b: Time to MBMS Data Transfer Value Part Coding 



Bits 
87654321 

00000000 Is 

00000001 2s 
00000010 3s 

11111111 256s 



£75/ 



3GPP TS 48.018 version 11.3.0 Release 11 



176 



ETSI TS 148 018 V1 1.3.0 (2013-07) 



1 1 .3.93 MBMS Session Repetition Number 

The MBMS Session Repetition Number denotes the repetition number of the MBMS session as defined in 3GPP TS 
23.246 [32]. The element coding is: 

Table 11.3.93: MBMS Session Repetition Number IE 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3 


MBMS-Session-Repetition-Number AVP encoded as in 3GPP TS 
29.061 [31], excluding AVP Header fields as defined in IETF RFC 

3588 [33]. 



1 1 .3.94 Inter RAT Handover Info 

This information element contains UTRAN related information needed to be transferred to the target RNC during a PS 
Handover to UTRAN. The element coding is: 

Table 11.3.94: Inter RAT Handover Information coding 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octets 3-? 


Inter RAT Handover Information coded as specified in 3GPP 
Technical Specification 25.331 



1 1 .3.95 PS Handover Command 

This information element contains the radio interface message to be sent to the mobile station. 
The element coding is: 

Table 11.3.95: PS Handover Command coding 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2 2a 


Length Indicator 


Octet 3-? 


Rest of element coded as a complete PS Handover Command 

radio interface message as defined in 3GPP TS 44.060 (carrying 

the PS Handover to A/Gb Mode Payload] 



1 1 .3.95a PS Handover Indications 

The PS Handover Indications information element provides indications related to the PS Handover procedure. The 
element coding is: 

Table 11.3.95a.a: PS Handover Indications IE 





8 


7 


6 


1 5 1 4 1 


3 


2 


1 1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 








Spare 






1 SI/PSI 1 



Table 11. 3.95a.b: "SI/PSI" coding 



coding 


Semantic 





SI/PSI not requested 


1 


SI/PSI requested 
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11. 3.95b SI/PSI Container 

The SI/PSI Container information element provides the (Packet) System Information messages of the GSM target cell 
that are required by the mobile station for PS Handover. The element coding is: 

Table 11.3.95b.a: SI/PSI Container coding 





8 


7 


6 5 4 


3 


2 


1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3 






Number of SI/PSI 






Type 1 


Octet 4-n 


SI/PSI 



Type: This field indicates the type of the (Packet) System Information messages provided by the target cell. The Type 
field is coded as shown below: 

Table 11.3.95b.b: Type coding 



Coding 


Semantic 





SI messages as specified for BCCH (3GPP TS 44.018) follow 


1 


PSI messages as specified for PBCCH (3GPP TS 44.060) follow 



Number of SI/PSI: This field indicates the number of (Packet) System Information messages contained in the SI/PSI 
field. For (Packet) System Information messages with multiple instances, each instance is counted as one SI/PSI 
message. The Number of SI/PSI field is coded as shown below: 

Table 11. 3.95b.c: Number of SI/PSI coding 



Coding 


Semantic 


000 0000 


"SI/PSI" follows 


000 0001 


1 "SI/PSI" follow 


' 


" 


111 1111 


127 "SI/PSI" follow 



SI/PSI: This field contains either a list of System Information or a list of Packet System Information messages of the 
GSM target cell that are required by the mobile station for PS Handover as specified in 3GPP TS 44.060. The number 
of (Packet) System Information messages is indicated in the Number of SI/PSI field specified above. Furthermore: 

- If the Type field indicates that "SI messages as specified for BCCH (3GPP TS 44.018) follow" then the SI/PSI 
field contains the subset of System Information message instances encoded for BCCH as specified in 

3GPP TS 44.018. Each System Information message contains the Message type octet followed by all the lEs 
composing the message payload. Each message is 21 octets long. 

- If the Type field indicates that "PSI messages as specified for PBCCH (3GPP TS 44.060) follow" then the SI/PSI 
field contains the subset of Packet System Information message instances encoded for PBCCH as specified in 
3GPP TS 44.060. Each Packet System Information message contains the MESSAGE_TYPE field followed by the 
PSI message content. Each message is 22 octets long. 
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11. 3.95c Active PFCs List 

This information element contains the Packet Flow Identifiers of the PFCs that are active in the source BSS at the time 
the PS Handover Required message is sent. The element coding is: 

Table 11. 3.95c.a: Active PFCs List IE 





8 7 6 5 4 3 


2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


Number of PFCs 


Octet 4 


PFI(1) 


Octet 5 


PFI (2) 


" 


" 


Octet ? 


PFI (n) 



Number of PFCs: Number of PFCs for which corresponding Packet Flow Identifiers are provided. The "Number of 
PFCs" parameter is coded as shown below: 

Table 11.3.95c.b: Number of PFCs 



Coding 


Semantic 


0000 0000 


Reserved 


0000 0001 


1 PFC 






0000 1011 


1 1 PFCs 


0000 1100 


Reserved 


' 


" 


1111 1111 


Reserved 



PFI: Packet Flow Identifier. Coded as the value part of the Packet Flow Identifier information element in 
3GPP TS 24.008, not including 3GPP TS 24.008 lEI. This IE shall not contain any pre-defined PFIs. 

11.3.96 Velocity Data 

This is a variable length information element providing an estimate of a velocity data. The element coding is: 

Table 11.3.96: Velocity Data IE 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 

to 
Octet n 


The rest of the information element contains an octet sequence 
identical to that for Description of Velocity defined in 3GPP TS 

23.032. 



1 1 .3.97 DTM Handover Command 

This information element contains the radio interface message to be sent to the mobile station. 
The element coding is: 
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Table 11.3.97: DTM Handover Command coding 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3-? 


Rest of element coded as a complete DTM Handover Command 

radio interface message as defined in 3GPP TS 44.060 (carrying 

the DTM Handover to A/Gb Mode Payload) 



11.3.98 CS Indication 

This information element indicates to the target BSS that this PS Handover is part of a DTM Handover Procedure. 
The element coding is: 

Table 11.3.98: CS Indication coding 





8 


7 


6 1 5 1 4 1 3 


2 


1 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3 


CS Indication Contents 



CS Indication Contents: This identifies a particular handover attempt for this MS. This shall be identical to the PS 
Indication Contents value in the corresponding PS Indication IE included in the Old BSS to New BSS Information IE 
(see 3GPP TS 48.008). The choice of the value of this field is implementation specific, with the requirement that 
consecutive handover attempts for the same mobile station shall not have the same CS Indication Contents value. 

1 1 .3.99 Requested GANSS Assistance Data 

This information element provides the information on which GANSS Assistance Data has been requested. The element 
coding is: 

Table 11.3.99: Requested GANSS Assistance Data IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-n 


Rest of element coded as the value part defined in 

3GPP TS 49.031 , not including 3GPP TS 49.031 lEI and 

3GPP TS 49.031 octet length indicator 



1 1 .3. 1 00 GANSS Location Type 

This information element provides the GANSS Location Type. The element coding is: 

Table 11.3.53: Location Type IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


Rest of element coded as the value part defined in 

3GPP TS 49.031 , not including 3GPP TS 49.031 lEI and 

3GPP TS 49.031 octet length indicator 



11.3.101 GANSS Positioning Data 

This information element provides GANSS Positioning Data. The element coding is: 
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Table 11.3.55: Positioning Data IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3-n 


Rest of element coded as the value part defined in 

3GPP TS 49.031 , not including 3GPP TS 49.031 IE! and 

3GPP TS 49.031 octet length indicator 



1 1 .3.1 02 Flow Control Granularity 

This information element provides the granularity to be used for deriving the Flow Control parameters values in the 
BVC Bucket Size IE, the BVC Bucket Leak Rate IE and the PFCflow control parameters IE when the Gigabit Interface 
feature is negotiated. The element coding is: 

Table 11.3.102: Flow Control Granularity IE 





8 


7 


6 5 4 


3 


2 1 


octet 1 


IE! 


octet 2, 2a 


Length Indicator 


octet 3 






Reserved 




Granularity 



Table 11. 3.102.a: "Granularity" coding 



coding 


Semantic 


00 


1 00 octets or bits/s increments 


01 


1000 octets or bits/s increments 


10 


1 0000 octets or bits/s increments 


11 


100000 octets or bits/s increments 



11.3.103 eNB Identifier 

This information element contains the information required to identify an eNB within a PLMN. 
The element coding is: 

Table 11.3.103: eNB Identifier coding 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octets 3-7 


Octets 3 to 7 contain the value part (starting with octet 2) of the 

Tracking Area Identity IE defined in 3GPP TS 24.301 [37], not 

including 3GPP TS 24.301 lEI [37] 


Octet 8-n 


Global eNB ID 



Octets 8-n contain the Global eNB ID (see 3GPP TS 36.413 [36] sub-clause 9.3.4, Global -ENB-ID Sequence) of the 
eNodeB. 
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1 1 .3.1 04 E-UTRAN Inter RAT Handover Info 

This information element contains E-UTRAN related information needed to be transferred to the target eNB during a 
PS Handover to E-UTRAN. The element coding is: 

Table 11.3.104: E-UTRAN Inter RAT Handover Information coding 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octets 3-? 


Formatted and coded according to the UE-EUTRA-Capability IE 

defined in 3GPP Technical Specification 36.331 . The most 

significant bit of the first octet of the octet string contains bit 8 of 

the first octet of the IE. 



1 1 .3.105 Subscriber Profile ID for RAT/Frequency priority 

This information element may be used by the BSS to provide individual priorities (see 3GPP TS 44.060) to mobile 
stations. 

The element coding is: 

Table 11.3.105.1 : Subscriber Profile ID for RAT/Frequency priority coding 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2 


Length Indicator 


Octet 3 


Octet 3 contains the value part of the Subscriber Profile ID for 
RAT/Frequency priority IE. 



Octet 3 contains a number in binary representation ranging from to 255. The Subscriber Profile ID for 
RAT/Frequency priority is given by the indicated value -i-l. 

1 1 .3.1 06 Request for Inter-RAT Handover Info 

The Request for Inter RAT Handover Info information element provides the request from the BSS to the SGSN for the 
Inter RAT Handover Info IE for UTRAN or E-UTRAN Inter RAT Handover Info or both to the BSS necessary for inter- 
RAT PS Handover procedure to UTRAN or E-UTRAN or both. The element coding is: 

Table 11.3.106.a: Request for Inter RAT Handover Info IE 





8 


7 


6 1 5 1 4 1 


3 


1 2 1 1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


Spare 


E-UTRAN 
Inter RAT 
Handover 

Info 

Req 


Inter RAT 
Handover 
Info Req 



Table 11. 3.1 06.b: "Inter RAT Handover Info Req" coding 



Coding 


Semantic 





Inter RAT Handover Info not requested 


1 


Inter RAT Handover Info requested 



Table 11. 3.1 06.c: "E-UTRAN Inter RAT Handover Info Req" coding 



coding 



Semantic 
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E-UTRAN Inter RAT Handover Info not requested 


1 


E-UTRAN Inter RAT Handover Info requested 



1 1 .3.1 07 Reliable Inter-RAT Handover Info 

The Reliable Inter RAT Handover Info information element provides to the target BSS the indication that the source 
BSS has received the Inter RAT Handover Info for UTRAN from the SGSN in the CREATE-BSS-PFC-PDU or in the 
PS-HANDOVER-COMPLETE- ACK PDU upon successful completion of PS handover or a PS-HANDOVER- 
REQUEST PDU with 'Reliable Inter RAT Handover Info Indicator' set to '1'. The element coding is: 

Table 11. 3.1 07.a: Reliable Inter RAT Handover Info IE 





8 


7 


6 


1 5 1 4 1 


3 


2 


1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


Spare 


Reliable 

Inter RAT 

Handover 

Info 

Indicator 



Table 11.3.107.b: "Reliable Inter RAT Handover Info Indicator' coding 



Coding 


Semantic 





Inter RAT Handover Info not reliable 


1 


Inter RAT Handover Info reliable 



11.3.1 08 SON Transfer Application Identity 

This information element specifies the addressed SON Transfer application within the target BSS node. The element 
coding is: 

Table 11.3.108: SON Transfer Application Identity IE 





8 


7 


1 6 1 5 1 4 1 3 1 


2 


1 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3-m 


SON Transfer Application Identity 



SON Transfer Application Identity: This field is encoded as the SON Transfer Application Identity IE as defined in 
3GPPTS 36.413 [36]. 

11.3.109 CSG Identifier 

The CSG Identifier information element indicates the identifier of the Closed Subscriber Group within the PLMN, as 
defined in [40], and the cell access mode of the CSG cell as defined in [22], [39]. The element coding is: 

Table 11.3.109.a: CSG Identifier IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octets 3-6 


Octets 3 to 6 contain the CSG Identity (CSG-ID) of the cell (defined in 

3GPP TS 23.003) as reported by the mobile station (see 3GPP TS 

44.060). Bits 4 to 8 of octet 6 are spare and set to zero. 


octet 7 


Spare 


Cell 

Access 

Mode 
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Table 11.3.109.b: Cell Access Mode field element details 



Cell Access Mode (bit 1 of octet 7) 

This field indicates the cell access mode of the cell as reported by the mobile 

station. 

Bit 

1 

CSG cell 

1 Hybrid cell 



Spare bits are reserved and coded with zeroes. 

11.3.110 Tracking Area Code 

The TAC information element provides an unambiguous identification of tracking areas needed for routing of the PS 
handover signalling to the target cell. The element coding is: 

Table 11.3.110: TAC IE 





8 7 6 5 4 3 2 1 


octet 1 


IE! 


octet 2, 2a 


Length Indicator 


octets 3-5 


Octets 3 to 5 contain the value part (starting with octet 2) of the TAC 
/E defined in 3GPP TS 24.301 . 



11.3.111 Redirect Attempt Flag 

This information element provides control information for the MOCN rerouting procedure. It indicates that the CN shall 
include in the answer either Redirection Indication IE or Redirection Completed IE. 



The element coding is: 



Table 11.3.111: Redirect Attempt Flag IE 





8 


7 


6 


1 5 1 4 1 


3 


2 


1 1 


Octet 1 


IE! 


Octet 2, 2a 


Length Indicator 


Octet 3 


spare 



11.3.112 Redirection Indication 

This information element provides control information for the MOCN rerouting procedure. It indicates that the CN 
requests rerouting by the BSS to another CN operator. The Reroute Reject cause is given. 

Table 11.3.112: Redirection Indication IE 





8 7 6 5 4 3 2 


1 1 1 


Octet 1 


IE! 


Octet 2, 2a 


Length indicator 


Octet 3 


Reroute Reject Cause value 



Reroute Reject cause value (octet 3) 

Bits 
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8 


7 


6 


5 


4 


3 


2 


1 




























Reserved 



















1 





Reserved 



















1 


1 


PLMN not allowed (meaning is defined in 3GPP TS 
24.008 [11]) 
















1 








location area not allowed (meaning is defined in 
3GPPTS 24.008 [11]) 
















1 





1 


roaming not allowed in this location area (meaning 
is defined in 3GPP TS 24.008 [11]) 
















1 


1 





GPRS services not allowed in this PLIVIN (meaning 
is defined in 3GPP TS 24.008 [11]) 
















1 


1 


1 


no suitable cell in location area (meaning is defined 
in 3GPPTS 24.008 [11]) 











1 














CS/PS domain registration coordination required 
(meaning defined in 3GPP TS 23.251 [43]) 











1 











1 


Reserved 


1 


1 


1 


1 


1 


1 


1 


1 


Reserved 



11.3.113 Redirection Completed 



This information element provides control information for the MOCN rerouting procedure. It indicates that the reroute 
procedure is completed. 



The element coding is: 



Table 11.3.113: Redirection Completed IE 





8 


7 


6 


1 5 1 4 1 


3 


2 


1 1 


Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3 


Outcome value 



Outcome value (octet 3) 

Bits 

8 7 6 5 4 3 2 1 

00000000 Reserved 

1 MS is accepted 

1 IVIS is not accepted 

1 1 IVIS is already registered 

1 Reserved 

11111111 Reserved 



1 1 .3.1 1 4 Unconfirmed send state variable 

This IE indicates the value of the Unconfirmed send state variable as defined in 3GPP TS 44.064 [12]. 
The element coding is: 

Table 11.3.114: Unconfirmed send state variable IE 



8 



1 
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Octet 1 


lEI 


Octet 2, 2a 


Length Indicator 


Octet 3 


spare 


V(U) 
MSB 


Octet 4 


V(U) 



Octet 2 and bit 1 of octet 3 contain a number in binary representation ranging from to 5 1 1 . The least significant bit is 
bit 1 of octet 3, and the most significant bit is bit 1 of octet 2. 

11.3.1151 RAT Measurement Configuration 

The IRAT Measurement Configuration IE is used to indicate to the BSS which frequency measurement results of the 
source RAT shall be collected after a successful inter-system handover. The IRAT Measurement Configuration IE is 
used by the source RAT to specify the E-UTRA frequencies to be reported back to the source RAT (each of them 
associated with a measurement bandwidth), the minimum radio quality and the period of time that the measurements 
should last before triggering a HO Report for unnecessary handover to another RAT. 

NOTE 1: HO Report is defined in 3GPP TS 36.413 [36]. 

NOTE 2: The functionahty of Unnecessary IRAT HO is described in 3GPP TS 36.300 [45]. 

The element coding is: 

Table 11.3.115: IRAT Measurement Configuration IE 





8 7 


6 


1 5 1 4 1 3 1 2 1 1 1 


Octet 1 


lEI 


Octet 2 


Length Indicator 


Octet 3 


Spare 


REP 
UANT 


REPORTING_THRESHOLD 


Octet 4 


IVIeasurement Duration 


Octets 5-6 


E-ARFCN 


Octet 7 




Spare 


1 Measurement Bandwidth 


Octets 8-9 


E-ARFCN 1 


Octet 1 




Spare 


1 Measurement Bandwidth 


' 


' 


Octets m- 

(m+1) 


E-ARFCN 


Octet m-H2 




Spare 


Measurement Bandwidth 



REPORTING_THRESHOLD: defines the reporting threshold to be used for measurement results analysis according 
to REP_QUANT. This threshold is used to compare against the measurement results received from the MS. It is a value 
between and 63 encoded on 6 bits according to 3GPP TS 45.008 [44] sub-section 8.1.5.4. 

REP_QUANT: indicates the measurement quantity for E-UTRAN cells coded as follows: 0=RSRP 1=RSRQ. 

Measurement _Duration: defines (in seconds) how long the BSS shall collect the measurements results received from 
the MS after a successful inter-RAT handover. It is a number in binary representation ranging from 1 to 100. 

E- ARFCN: designates a specific E-UTRA frequency for which the target RAT should continue to collect the 
measurement results received from MS of this frequency. It is coded as a number in binary representation ranging from 
to 65535. 

Measurement Bandwidth: defines the measurement bandwidth of the E-UTRA frequency signalled in the two 
previous octets. It is coded on 3 bits according to 3GPP TS 44.018 [25]. 

11.3.116 SCI 

The SCI information element provides information on the service class of the user data. The element coding is: 
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Table 11.3.116-1: SCI IE 





8 7 6 5 4 3 2 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


Octet 3 contains the value part (octet 2) of the SCI IE defined in 
3GPPTS 29.281 [46]. 



Octet 3 specifies the Service Class value for LLC PDUs of applications benefitting from specific RRM behaviour. 

11.3.117 GGSN/P-GW location 

The GGSN/P-GW location information element provides information on the location of the GGSN/P-GW that encoded 
the SCI. The element coding is: 

Table 11.3.117-1: GGSN/P-GW location IE 





8 


7 


6 1 5 1 4 1 3 


2 


1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


octet 3 


GGSN/P-GW location 



In octet 3, bits 8 to 4 are spare, set to zero by the SGSN and shall be ignored by the BSS. The coding of bits 3 to 1 is 
specified in Table 1L3.1 17-2. 

Table 11.3.117-1: GGSN/P-GW location 



Octet 3 

Bit: 

321 


Semantic 


000 


HPLMN 


001 


VPLMN 


1 


Operator Group GGSN 


1 1 


Unknown 


1 to 1 1 1 


For future use (treat as VPLMN) 



The conditions under which the SGSN indicates the values defined in Table 11. 3. 117-1 are specified in 3GPP TS 
23.060 [7]. 

11.3.118 Selected PLMN ID 

The purpose of the Selected PLMN ID information element is to provide the SGSN with the PLMN ID selected by a 
mobile station supporting network sharing when network sharing is in use in a cell. 

Table 11.3.116: Selected PLMN ID IE 





8 7 6 


1 5 


4 


3 1 2 


1 1 


octet 1 


lEI 


octet 2, 2a 


Length Indicator 


Octet 3 


MCC dig 2 


MOO dig 1 


Octet 4 


MNCdig3 


MCC dig 3 


Octet 5 


MNCdig2 


MNCdig 1 



NOTE: The MCC and MNC value field is coded as specified within 3GPP TS 24.008 [11]. 



11.3.119 Priority Class Indicator 



This information element indicates that overload has occurred in the SGSN and traffic for the indicated priority class 
should be reduced. 
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Table 11.3.118: Priority Class Indicator IE 





8 


7 1 6 1 5 1 4 1 3 1 2 


1 1 


octet 1 


lEI 


octet 2 


Length Indicator 


octet 3 


Value part of Priority Class Indicator 



The Value part of Priority Class Indicator is coded as a bit string with length of 8. Each bit represents a kind of priority 
class as specified below. If a bit is set to '1', the signalling traffic of the respective priority class should be reduced. 

Bit (0) = A mobile station configured for "low access priority" as defined in TS 44.060. 

Bits (1...7) are spare. The SGSN shall set them to "0 ". The BSS shall ignore them. 



1 2 List of system variables 



12.1 General Variables 



Table 12.1.a: Procedure timers 



Timer 
mnemonic 


Value range 


Notes 


Relation to other timers 


11 


1 s < T1 < 30 s 


Guards the {un)blocking procedures 


none 


T2 


1 s<T2< 120 s 


Guards the reset procedure 


none 


13 


0,1 s<T3< 10 s 


Guards the suspend procedure 


none 


14 


0.1 s<T4< 10 s 


Guards the resume procedure 


none 


T5 


1 s < T5 < 30 s 


Guards the Radio Access Capability 
Update procedure 


none 


T6 


0,1 s<T6< 10 s 


Guards the DOWNLOAD-BSS-PFC PDU 


none 


T7 


0,1 s<T7<10s 


Guards the CREATE-BSS-PFC PDU 


none 


18 


0,1 s<T8< 10 s 


Guards the MODIFY-BSS-PFC PDU 


none 


19 


Same as 1331 4 

READY timer in 

3GPPTS 24.008. 

IVIinimum 6 s 


This is the Packet Flow Timer (PFT) and 
holds the maximum time the BSS may 
store a BSS PFC while no uplink data is 
transmitted 


Cannot exceed the value of the 
READY timer for this MS unless 
READY timer is less than 6 s. 


no 


0,5s<T10<10s 


Guards the PFC queuing procedure 


T1 < T7 


111 


0,1 s<T11 < 10s 


Guards the MBMS Session Start, IVIBMS 
Session Update and MBIVIS Session Stop 
procedures 


none 


T12 


0,5s<T12<10s 


Guards the PS Handover Required 
procedure in the BSS 


none 


113 


0,5s<T13<10s 


Guards the PS Handover Request 
procedure in the SGSN 


none 


114 


0,5s<T14< 10s 


Guards the PS Handover Complete 
procedure in the SGSN 


none 


115 


O&M 


Overload timer in BSS, see sub-clause 
8.6.1 


T15<T16 


116 


O&M 


Overload timer in BSS, see sub-clause 
8.6.1 


none 



Table 12.1.b: Procedure retry counters 



Retry mnemonic 



I Retry value | 



Notes 
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BVC-BLOCK-RETRIES 


3 


none 


BVC-UNBLOCK-RETRIES 


3 


none 


BVC-RESET-RETRIES 


3 


none 


SUSPEND-RETRIES 


3 


none 


RESUME-RETRIES 


3 


none 


RA-CAPABILITY-UPDATE-RETRIES 


3 


none 


DOWNLOAD-BSS-PFC-RETRIES 


3 


none 


CREATE-BSS-PFC-RETRIES 


3 


none 


MODIFY-BSS-PFC-RETRIES 


3 


none 


MBMS-SESSION-START-REQUEST-RETRIES 


3 


none 


MBMS-SESSION-STOP-REQUEST-RETRIES 


3 


none 


MBMS-SESSION-UPDATE-REQUEST-RETRIES 


3 


none 



1 2.2 Flow control variables 



Table 12.2: Flow control variables 



Variable 
mnemonic 


Value range 


Notes 


Relation to other variables 


Th 


5 s < Th < 6 000 s 


Interval after Flow-Control-MS 
before SGSN may use SGSN 
generated Bmax and R 


none 


C 


1 s<C< 10s 


Minimum interval between sending 
of subsequent Flow Control PDUs 
for a given BVC or MS or PFC 


G<Th 


Tf 


5 s < Tf < 6 000 s 


Interval after Flow-Control-PFC 
before SGSN may use SGSN 
generated Bmax and R 


Tf>G 
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3 


Indication of selected PLIVIN to the SGSN 


11.1.0 


GP-56 
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5 
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1 
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1 
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1 
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3 
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